🛠️

【DataSpider】DB_BackUpライブラリ

2022/06/07に公開

最初に

この記事ではDataSpiderのライブラリとなる[DB_BackUp]ライブラリについて解説します。

ライブラリ群の全体の話についてはこちらの本記事に記載しています。

ライブラリの特徴

本ライブラリはデータベースがDr.Sumに限定されているものです。データベースのバックアップ自体は絶対に行うべきなので、他DBを使用されている場合は、ご自身でバックアップ処理を追加してください。

Dr.Sumにはバックアップコマンドを呼び出すだけでバックアップがおこなえる機能があります。
今回はそのバックアップコマンドを呼び出すバッチを作成し、DataSpiderからパラメーターを渡して、バックアップを実行する仕組みを作成します。

ライブラリの詳細

引き渡し変数

DB_Backupライブラリで必要な変数はこちら。

親スクリプトから渡してほしい変数はこちらの1つです。
　・DB名
です。
親スクリプトからはDB名を持たせればOKです。

親スクリプトからの変数の渡し方はこちら。

親スクリプトからは自身の変数である
　・DB名
を渡します。

処理の流れ

[DB_BackUp]ライブラリはコンポーネントが少ないです。しかもTry-Catch文がほとんどで、実際はバッチコマンドを処理しているだけですので1つですね。

バッチファイルを用意する

まずはバッチファイルを用意して、DataSpiderの入っているサーバに配置しましょう。

バッチファイルの中身はこちらです。

@echo off

cd C:\drsum56\AdminTools\cmd\JPN

rem データベースのバックアップ
dwdb_backup "localhost" 6001 %1 %2 "backup" %3 %4 %5

exit /b

cdはDr.Sumのバッチファイルが格納されているファイルを指します。
今回はdwdb_backup.batをキックします。

dwdb_backup "localhost" 6001 %1 %2 "backup" %3 %4 %5

dwdb_backupのあとにパラメータを渡しています。
%1〜%5はDataSpiderから渡すパラメーターです。

BackUpコンポーネント

バッチファイルが設置できたら、DataSpider側に戻りましょう。
外部アプリケーション起動処理コンポーネントを用意します。

起動コマンドは先ほど置いたバッチファイルの場所を指します。

そして起動引数がバッチファイルの %1〜%5 に対応します。

バッチ	DataSpider
%1	${DS User ID}
%2	${DS Password}
%3	${DB名}
%4	"C:\backup\db"
%5	${DB名}

これでOKです。
Dr.Sumのユーザー名やパスワードはDataSpiderの中で保持しています。
（グローバルにした方がいいんだろうけど、とりあえずはスクリプト変数に保持しています）

zip圧縮コンポーネント

Dr.Sumのデータベースフォルダは圧縮率が高いです。データベースの大きさによってはディスクが枯渇する場合もあるので、適宜圧縮や別サーバーへの退避を行いましょう。
こちらでは圧縮をし、元のバックアップファイルは削除する運用にしています。

DB名は変数を用います。もちろんフォルダパスも変数をつかっていただいて問題ございません。

この圧縮オプションが重要です。
[圧縮先に既に存在した場合にエラー]にチェックを外しましょう。前日のzipファイルが残っている前提ですので上書きで消すようにします。

注意：圧縮したフォルダは解凍してちゃんと復元されるかを確認しましょう

ファイル削除コンポーネント

圧縮前のバックアップフォルダを削除します。

フォルダ内にファイルが残っているとエラーになってしまうので、[強制削除しない]のチェックを外します。また仮にファイルがなかった場合も処理を進めたいので、[ファイル/ディレクトリが存在しない場合はエラー]のチェックも外します。

[DB_BackUp]ライブラリは以上で終了です。

バックアップの世代管理とタイミング

バックアップを取る世代管理とタイミングについて記載します。

世代管理は過去何回分のバックアップを保持するかです。
今回の処理では１世代のみの管理としています。
${DB名} に本日日付をつけたり、この処理の終わりに旧世代のバックアップファイルを削除すれば世代管理も可能ですが、運用上1ファイルで良いかなと考えています。

またバックアップを取るタイミングは夜間連携の前としていて、夜間連携とは独立させています。
下図のMaintenanceスクリプトが単独で流れています。

なぜバックアップを
・夜間処理の前に流すのか
・夜間処理のスクリプトと独立させているのか
については以下の理由がございます。

まず、ぼくのおこなっているデータ連携は日中は処理をせずに夜中にだけ流しています。
「なら夜間処理が終わってからバックアップすればいいじゃん」って思いますが、エラー発生時の復旧のことを考えています。

さまざまな場合を想定して、夜間処理で取り返しのつかないエラーが出てデータベースもテーブルも壊れてしまったとします。その状態のバックアップがあっても意味ないですよね？
夜間処理前のバックアップがあれば、そのデータベースで復旧することができます。

そしてぼくの夜間処理はすべてエラーが復旧したときに、再実行したらデータが復元されるように設計しています。
[昨日のデータが多重化される]という現象は回避しています。エラーになっていざという時に、復旧しやすい設計なのですね^^
スクリプトを再実行するときにバックアップが走ったらめんどうです。そのためにバックアップと夜間処理のスクリプトは独立させています。

この細かな処理の気配りが、運用を楽にするのです。

最後に

DB_BackUpライブラリについては以上となります。
バックアップは備えあれば憂いなしという領域ですが、いざという時になくては困るものです。
ただしバックアップをとりすぎるとハードディスクの圧迫につながりますので、運用を考えた設計をおこないましょう。

他のライブラリについてもこちらで解説していますので、ぜひご覧になってください。