WEB+DB PRESS Vol.59 は大規模データ分析がすてきな感じですが、今回もミックさんの連載をまずチェック。
今回はバックアップとリカバリ、ですね。私もDB Magazineの特集に巻き込まれ(?) かなり苦労した部分でありますが、これをミックさんがどう料理するか楽しみです。
まず私は専用のツールなど使ったことがなかったのでSynthetic Full Backup知りませんでした。
説明されれば納得なのですが。。。。まぁこういうのがWikipediaにも掲載されているんだから、世の中すすみましたねー、。
増分バックアップ(Wikipedia)
![WEB+DB PRESS Vol.59]()
WEB+DB PRESS Vol.59
WEB+DB PRESS編集部
(1) 表1 バックアップ方法の比較
この表までの文も、表も申し分ないものですので、ここでは触れられていない観点について補足することにします。
その観点は、差分バックアップと、増分バックアップを「どこ」から生成するか、です。
フルバックアップは当然もとのデータベースファイルからしか作成できませんが、差分バックアップと増分バックアップは、以下のものをソースとして作成できます。
(i) データベースファイル
(ii)トランザクションログファイル
データベースファイルから生成する場合は、前回成功したバックアップからの変更点を物理的に(たとえばブロック単位など)スキャンして、抽出する必要があります。(抽出のパフォーマンスは地道に改善されています。Oracleの例) しかし、トランザクションログファイルを利用する場合は、通常の運用でトランザクションファイルは作成していますので、それを消さないように保存する(アーカイブ)だけでよく、抽出は必要はありません。
(ログがローテーションにより再利用されるようなしくみの場合は、そこからコピーする必要はあります)
このような観点からOracle, SQL Server, IBM DB2, PostgreSQL, MySQLを見ると以下のように分類できます。
(i) データベースファイルから抽出: Oracleの差分・増分、SQL Serverの差分、IBM DB2の差分・増分
(ii)トランザクションログファイルを利用: SQL Serverの増分、PostgreSQLの増分、MySQLの増分
トランザクションファイルのみに差分・増分のバックアップを頼っているPostgreSQLとMySQLは任意の期間での差分ファイルというのは生成できないので、増分バックアップのみできて、差分バックアップはできない、と考える方がしっくりきます。
トランザクションログファイルを増分バックアップとして使うことにはいくつか短所があります。
・リストア・リカバリ時に冗長な処理が多い
トランザクションログは実際のデータベースに変更を行いコミットされた時点で書き出されます。そのため、たとえばその変更がデータベースの同一のブロックに対して行われたている場合でも、その同一ブロックに対する操作を愚直に一つずつ再現しながらリストア・リカバリしていきます。一つのブロックへの更新が単位時間あたりに100回行われたとすると100回の処理を時系列に行うことになります。
データベースファイルから差分・増分バックアップを取得した場合は、単純にそのブロックを一回書き戻すだけですので、それに比較すると明らかに冗長で時間がかかります。
また、MySQLのバイナリログのようにSQL文に変換してから、リストア・リカバリの入力として使うものは、単純にSQL文の実行になりますので、再度SQL文のパーズから実行までを行うので、その分さらにオーバヘッドがかかります。
・処理速度が遅い
先ほどあげた冗長な処理のために、データベースからの差分・増分を適用する(バイナリ)に比較して処理速度は遅くなります。
・バックアップとしてのファイルが、トランザクションログ運用の影響を受けます。
増分バックアップのイメージは、その増分取得の時点でのまとまりのあるファイル群ですが、元々がトランザクションログですので、バックアップファイルがトランザクションログの運用の影響を受けます。たとえばPostgreSQLでは16MB(デフォルト)のファイル群として生成されますし、MySQLではmax_binlog_sizeサイズを明示的に指定しなければ1GBのファイル群になります。(ただし、FLUSH LOGS;コマンドを発行すると、その時点で次のファイルに切り替わりますし、一つのトランザクションが二つのログファイルにまたがることができないため、そのような場合は、max_binlog_sizeを超えるサイズのログファイルも作成されます)
いずれにせよ、リストア・リカバリにちょうどいい形で運用できるというわけではありません。
SQL Serverが差分バックアップだけデータベースから抽出、増分バックアップはトランザクションログに頼っている、という構成が興味深いですね。実際のイメージは以下の松本崇博さんのブログエントリがわかりやすいです。
ログ バックアップと差分バックアップの比較
(2) COLUMN そのほかのバックアップの分類
「これが意味することは、基本的に、論理バックアップをリカバリ時のベースバックアップに使うことはできない、ということです」とありますがMySQLでは利用することがままあります。データ的に一貫性のあるバックアップがとれていれば、それをベースにログを適用することによりロールフォワードのリカバリが可能です。MySQLでの詳細は以下の松信さんの資料をご参照ください。
MySQLのバックアップ・リカバリ(OSC 2005)
(3) COLUMN リカバリなんてしたくない
参考文献[2] Part 5でもとりあげましたが、Linuxをご利用の方は是非DRBDを試してみてください。DRBDはLinuxプラットフォームで動作するオープンソースのネットワークミラーリングソフトウエアです。カーネル2.6.33からメインラインに組み込まれています。
(4) OSのスナップショット機能
LinuxのLVMのようにOSのスナップショット機能でバックアップを取得することも可能です。MySQLで利用するイメージは漢のコンピュータ道の以下のエントリをご参照ください。
MySQLバックアップ頂上決戦！！ LVMスナップショット vs InnoDB Hot Backup
詳細な手順はInterDBの鈴木さんが書いた参考文献[2] のPart2にもあります。
今回は元原稿の表1.をまじめにつついていたら、お時間となってしまいました。さすがミックさん、限られた分量でうまくまとまっています。是非みなさんも本を購入して「まとめ」部分のお言葉を三回口に出して唱えてみましょう(笑) さらに調べたい、という向きには、まずは以下の参考文献くらいから探索してみてはいかがでしょうか?
(次回は、恒例のFirebird編です)
[参考文献]
[1] Oracle & SQL Server対応 バックアップとリカバリ基礎と再点検 月刊DBマガジン 2007/11
OracleとMicrosoft SQL Serverについてうまくまとめられています。
[2] オープンソースDB障害対策マニュアル 月刊DBマガジン 2010/03
MySQL, PostgreSQL, Firebirdについてうまくまとめられています。木村のほうで概略と、DRBD部分を記述しました。概略を書いたPart1がミックさんの本稿と多くの部分で重なります。
[3] DB2のインクリメンタルバックアップの利用
DB2のバックアップについてまとめられています。ミックさんの記事から参照されています。
PlanetMySQL Voting: Vote UP / Vote DOWN
今回はバックアップとリカバリ、ですね。私もDB Magazineの特集に巻き込まれ(?) かなり苦労した部分でありますが、これをミックさんがどう料理するか楽しみです。
まず私は専用のツールなど使ったことがなかったのでSynthetic Full Backup知りませんでした。
説明されれば納得なのですが。。。。まぁこういうのがWikipediaにも掲載されているんだから、世の中すすみましたねー、。
増分バックアップ(Wikipedia)
WEB+DB PRESS Vol.59
WEB+DB PRESS編集部
(1) 表1 バックアップ方法の比較
この表までの文も、表も申し分ないものですので、ここでは触れられていない観点について補足することにします。
その観点は、差分バックアップと、増分バックアップを「どこ」から生成するか、です。
フルバックアップは当然もとのデータベースファイルからしか作成できませんが、差分バックアップと増分バックアップは、以下のものをソースとして作成できます。
(i) データベースファイル
(ii)トランザクションログファイル
データベースファイルから生成する場合は、前回成功したバックアップからの変更点を物理的に(たとえばブロック単位など)スキャンして、抽出する必要があります。(抽出のパフォーマンスは地道に改善されています。Oracleの例) しかし、トランザクションログファイルを利用する場合は、通常の運用でトランザクションファイルは作成していますので、それを消さないように保存する(アーカイブ)だけでよく、抽出は必要はありません。
(ログがローテーションにより再利用されるようなしくみの場合は、そこからコピーする必要はあります)
このような観点からOracle, SQL Server, IBM DB2, PostgreSQL, MySQLを見ると以下のように分類できます。
(i) データベースファイルから抽出: Oracleの差分・増分、SQL Serverの差分、IBM DB2の差分・増分
(ii)トランザクションログファイルを利用: SQL Serverの増分、PostgreSQLの増分、MySQLの増分
トランザクションファイルのみに差分・増分のバックアップを頼っているPostgreSQLとMySQLは任意の期間での差分ファイルというのは生成できないので、増分バックアップのみできて、差分バックアップはできない、と考える方がしっくりきます。
トランザクションログファイルを増分バックアップとして使うことにはいくつか短所があります。
・リストア・リカバリ時に冗長な処理が多い
トランザクションログは実際のデータベースに変更を行いコミットされた時点で書き出されます。そのため、たとえばその変更がデータベースの同一のブロックに対して行われたている場合でも、その同一ブロックに対する操作を愚直に一つずつ再現しながらリストア・リカバリしていきます。一つのブロックへの更新が単位時間あたりに100回行われたとすると100回の処理を時系列に行うことになります。
データベースファイルから差分・増分バックアップを取得した場合は、単純にそのブロックを一回書き戻すだけですので、それに比較すると明らかに冗長で時間がかかります。
また、MySQLのバイナリログのようにSQL文に変換してから、リストア・リカバリの入力として使うものは、単純にSQL文の実行になりますので、再度SQL文のパーズから実行までを行うので、その分さらにオーバヘッドがかかります。
・処理速度が遅い
先ほどあげた冗長な処理のために、データベースからの差分・増分を適用する(バイナリ)に比較して処理速度は遅くなります。
・バックアップとしてのファイルが、トランザクションログ運用の影響を受けます。
増分バックアップのイメージは、その増分取得の時点でのまとまりのあるファイル群ですが、元々がトランザクションログですので、バックアップファイルがトランザクションログの運用の影響を受けます。たとえばPostgreSQLでは16MB(デフォルト)のファイル群として生成されますし、MySQLではmax_binlog_sizeサイズを明示的に指定しなければ1GBのファイル群になります。(ただし、FLUSH LOGS;コマンドを発行すると、その時点で次のファイルに切り替わりますし、一つのトランザクションが二つのログファイルにまたがることができないため、そのような場合は、max_binlog_sizeを超えるサイズのログファイルも作成されます)
いずれにせよ、リストア・リカバリにちょうどいい形で運用できるというわけではありません。
SQL Serverが差分バックアップだけデータベースから抽出、増分バックアップはトランザクションログに頼っている、という構成が興味深いですね。実際のイメージは以下の松本崇博さんのブログエントリがわかりやすいです。
ログ バックアップと差分バックアップの比較
(2) COLUMN そのほかのバックアップの分類
「これが意味することは、基本的に、論理バックアップをリカバリ時のベースバックアップに使うことはできない、ということです」とありますがMySQLでは利用することがままあります。データ的に一貫性のあるバックアップがとれていれば、それをベースにログを適用することによりロールフォワードのリカバリが可能です。MySQLでの詳細は以下の松信さんの資料をご参照ください。
MySQLのバックアップ・リカバリ(OSC 2005)
(3) COLUMN リカバリなんてしたくない
参考文献[2] Part 5でもとりあげましたが、Linuxをご利用の方は是非DRBDを試してみてください。DRBDはLinuxプラットフォームで動作するオープンソースのネットワークミラーリングソフトウエアです。カーネル2.6.33からメインラインに組み込まれています。
(4) OSのスナップショット機能
LinuxのLVMのようにOSのスナップショット機能でバックアップを取得することも可能です。MySQLで利用するイメージは漢のコンピュータ道の以下のエントリをご参照ください。
MySQLバックアップ頂上決戦！！ LVMスナップショット vs InnoDB Hot Backup
詳細な手順はInterDBの鈴木さんが書いた参考文献[2] のPart2にもあります。
今回は元原稿の表1.をまじめにつついていたら、お時間となってしまいました。さすがミックさん、限られた分量でうまくまとまっています。是非みなさんも本を購入して「まとめ」部分のお言葉を三回口に出して唱えてみましょう(笑) さらに調べたい、という向きには、まずは以下の参考文献くらいから探索してみてはいかがでしょうか?
(次回は、恒例のFirebird編です)
[参考文献]
[1] Oracle & SQL Server対応 バックアップとリカバリ基礎と再点検 月刊DBマガジン 2007/11
OracleとMicrosoft SQL Serverについてうまくまとめられています。
[2] オープンソースDB障害対策マニュアル 月刊DBマガジン 2010/03
MySQL, PostgreSQL, Firebirdについてうまくまとめられています。木村のほうで概略と、DRBD部分を記述しました。概略を書いたPart1がミックさんの本稿と多くの部分で重なります。
[3] DB2のインクリメンタルバックアップの利用
DB2のバックアップについてまとめられています。ミックさんの記事から参照されています。
PlanetMySQL Voting: Vote UP / Vote DOWN
