Search
MENU
Search 
Category
この記事ではConnectのライブラリとなる[DB_BackUp]ライブラリについて解説します。
ライブラリ群の全体の話についてはこちらの本記事に記載しています。
本ライブラリはデータベースがDr.Sumに限定されているものです。データベースのバックアップ自体は絶対に行うべきなので、他DBを使用されている場合は、ご自身でバックアップ処理を追加してください。
Dr.Sumにはバックアップコマンドを呼び出すだけでバックアップがおこなえる機能があります。
今回はそのバックアップコマンドを呼び出すバッチを作成し、Connectからパラメーターを渡して、バックアップを実行する仕組みを作成します。
| Dr.Sumマニュアル:2-1 dwdb_backup(データベースをバックアップする) |
DB_Backupライブラリで必要な変数はこちら。
親スクリプトから渡してほしい変数はこちらの1つです。
です。
親スクリプトからはDB名を持たせればOKです。
親スクリプトからの変数の渡し方はこちら。
親スクリプトからは自身の変数である
を渡します。
[DB_BackUp]ライブラリはコンポーネントが少ないです。しかもTry-Catch文がほとんどで、実際はバッチコマンドを処理しているだけですので1つですね。
まずはバッチファイルを用意して、Connectの入っているサーバに配置しましょう。
バッチファイルの中身はこちらです。
@echo off
cd C:\drsum57\AdminTools\cmd\JPN
rem データベースのバックアップ
dwdb_backup "localhost" 6001 %1 %2 "backup" %3 %4 %5
exit /bcdはDr.Sumのバッチファイルが格納されているファイルを指します。
今回はdwdb_backup.batをキックします。
dwdb_backup “localhost” 6001 %1 %2 “backup” %3 %4 %5
dwdb_backupのあとにパラメータを渡しています。%1〜%5はConnectから渡すパラメーターです。
バッチファイルが設置できたら、Connect側に戻りましょう。外部アプリケーション起動処理コンポーネントを用意します。
起動コマンドは先ほど置いたバッチファイルの場所を指します。
そして起動引数がバッチファイルの %1〜%5 に対応します。
| バッチ | Connect |
|---|---|
| %1 | ${DS User ID} |
| %2 | ${DS Password} |
| %3 | ${DB名} |
| %4 | “C:\backup\db” |
| %5 | ${DB名} |
これでOKです。
Dr.Sumのユーザー名やパスワードはConnectの中で保持しています。
(グローバルにした方がいいんだろうけど、とりあえずはスクリプト変数に保持しています)
Dr.Sumのデータベースフォルダは圧縮率が高いです。データベースの大きさによってはディスクが枯渇する場合もあるので、適宜圧縮や別サーバーへの退避を行いましょう。
こちらでは圧縮をし、元のバックアップファイルは削除する運用にしています。
DB名は変数を用います。もちろんフォルダパスも変数をつかっていただいて問題ございません。
この圧縮オプションが重要です。
[圧縮先に既に存在した場合にエラー]にチェックを外しましょう。前日のzipファイルが残っている前提ですので上書きで消すようにします。
注意:圧縮したフォルダは解凍してちゃんと復元されるかを確認しましょう
圧縮前のバックアップフォルダを削除します。
フォルダ内にファイルが残っているとエラーになってしまうので、[強制削除しない]のチェックを外します。また仮にファイルがなかった場合も処理を進めたいので、[ファイル/ディレクトリが存在しない場合はエラー]のチェックも外します。
[DB_BackUp]ライブラリは以上で終了です。
バックアップを取る世代管理とタイミングについて記載します。
世代管理は過去何回分のバックアップを保持するかです。今回の処理では1世代のみの管理としています。
${DB名} に本日日付をつけたり、この処理の終わりに旧世代のバックアップファイルを削除すれば世代管理も可能ですが、運用上1ファイルで良いかなと考えています。
またバックアップを取るタイミングは夜間連携の前としていて、夜間連携とは独立させています。
下図のMaintenanceスクリプトが単独で流れています。
なぜバックアップを
については以下の理由がございます。
まず、私のおこなっているデータ連携は日中は処理をせずに夜中にだけ流しています。
「なら夜間処理が終わってからバックアップすればいいじゃん」って思いますが、エラー発生時の復旧のことを考えています。
さまざまな場合を想定して、夜間処理で取り返しのつかないエラーが出てデータベースもテーブルも壊れてしまったとします。その状態のバックアップがあっても意味ないですよね?
夜間処理前のバックアップがあれば、そのデータベースで復旧することができます。
そして私の夜間処理はすべてエラーが復旧したときに、再実行したらデータが復元されるように設計しています。
[昨日のデータが多重化される]という現象は回避しています。エラーになっていざという時に、復旧しやすい設計なのですね^^
スクリプトを再実行するときにバックアップが走ったらめんどうです。そのためにバックアップと夜間処理のスクリプトは独立させています。
この細かな処理の気配りが、運用を楽にするのです。
DB_BackUpライブラリについては以上となります。
バックアップは備えあれば憂いなしという領域ですが、いざという時になくては困るものです。
ただしバックアップをとりすぎるとハードディスクの圧迫につながりますので、運用を考えた設計をおこないましょう。
他のライブラリについてもこちらで解説していますので、ぜひご覧になってください。
Related article
Pick up
Ranking
Info
