GTM-MML4VXJ
Skip to main content
  1. ホーム >
  2. 製品 >
  3. ソフトウェア >
  4. ライブラリー >
  5. 特集 >
  6. WALが損失するという課題の解決(1/2)

富士通の技術者に聞く!PostgreSQL最新技術
WALが損失するという課題の解決(1/2)
PostgreSQLインサイド

富士通の技術者に聞く!PostgreSQL最新技術WALが損失するという課題の解決(1/2)PostgreSQLのエキスパート 綱川貴之 入社以来、データベース管理システムの開発・保守・サポートに従事。富士通ではPostgreSQLに最も精通していると技術者の一人。

データベースが企業システムの根幹を支えるのは既に周知のことだろう。しかし、世の中に絶対ということはなくトラブルは避けて通れない。データベースで最も困るトラブルといえばデータロストであろう。オープンソースデータベースであるPostgreSQLにも当然それを回避する仕組みが備わっているが、エンタープライズ利用を考えるとまだ足りない部分があるのが現実だ。
富士通では、これに対する解としてデータロストゼロを目指す「WALの二重化」機能を実装した。ここでは技術者がどのように機能を検討し開発したのか?その真相に迫る。

  • 1
  • 2

次へarrow-double

 [2015年9月25日掲載]

障害発生時、データベースを最新状態に復旧

―「自社製データベースにPostgreSQLを取り込んだ富士通の戦略とは?」の回で千田マネージャーよりPostgreSQLをエンタープライズ利用するためにWALの二重化機能を開発したと伺いました。どのような機能なのか具体的に教えてください。

綱川

ご存知のとおりPostgreSQLのトランザクション更新ログを「WAL(Write Ahead Logging)」と呼びます。PostgreSQLではこのWALを複数ファイルに分けて格納します。1つのファイルにログを書き尽くすと次のファイルに進み、すべて使いきると最初のファイルを改名して上書きしていくという動作を繰り返します。
私たちが開発したWALの二重化機能は、このWALと同じ内容を持つコピー(これを便宜上「二重化WAL」と呼びます)を別の場所に維持する機能です。これにより、障害発生直前の最新状態までデータベースを復旧できるようになります。

―PostgreSQLではWALのアーカイブ設定によりWALのコピーを別の場所に保管できると思いますがそれではダメなのですか?

綱川

仰るとおりPostgreSQLのメディアリカバリ機能では、バックアップデータとWALのコピー(これを便宜上「アーカイブWAL」と呼びます)、この2つを使用してデータベースを復旧します。ただ、アーカイブWALでは厳密には最新状態に復旧することができないのです。
たとえばディスクを2台使った最少構成のシステムを考えてみましょう。
ディスク1にはデータベースとWALを配置します。ディスク2には、データベースのバックアップとアーカイブWALを配置します。
このシステムにおいてディスク1が故障してアクセスできなくなったとします。この場合、どのように障害発生直前の状態までデータベースを復旧しますか?

―ディスク2にはリカバリーに必要なデータが揃っていますよね。ですから『故障したディスク1を新しいディスクに交換し、ディスク2にあるデータベースのバックアップからデータをリストアしたあとアーカイブWALを適用する』でしょうか

綱川

手順としてはそうなります。
ただ、この方法では先ほど説明したように少し過去の時点までしかデータベースを復旧できません。一部のWALがまだアーカイブされていないので、メディアリカバリ機能で利用できないからです。

―WALがアーカイブされていないとはどういうことでしょうか?

綱川

先ほどWALは複数のファイルに分割されて格納していると説明しました。このファイルを「WALセグメント」といい、1つのセグメントは16MBです。
WALセグメントが満杯になると、トランザクションの実行とは非同期にバックグラウンドでWALセグメントがアーカイブされて、先ほどの例でいうディスク2にコピーされます。
逆の言い方をすると、WALセグメントが満杯になるまではコピーはされないということです。つまり、ディスクの故障などが起きると"まだアーカイブされていないWALセグメントの分"だけトランザクションが失われるということです。

―だから最新状態に復旧できないのですね。

綱川

この"アーカイブされていないWAL"に含まれるトランザクションを失わないためにWALの二重化機能を開発しました。
WALには障害発生直前までのトランザクションが記録されているため、WALが格納されているディスクが故障するとデータが失われてしまいます。そこで"他のディスクにWALのコピーを常備しよう"というのが機能のコンセプトです。
メディアリカバリを行う際に、すべてのアーカイブWALを適用したあとで足りない情報を二重化WALから読み込んで適用します。これで、障害発生直前のトランザクションまで復旧できます。

再生時間:1分39秒

アニメーションでわかる「WALの二重化」機能

―すべてのトランザクションを復旧するにはアーカイブされていないWALも必要だからそのコピーを常に用意していることがWALの二重化ということですね。であれば、WALをバックアップ用ディスクに配置するという対応ではダメなのでしょうか?

綱川

たしかに、そうすればリカバリーに必要なデータがすべてバックアップ用ディスクに集められますね。しかしWALへの書き込みが失敗するとデータベースは停止してしまいます。つまりそのような構成では"バックアップ用のディスクが故障したときにもシステムが止まる"ということになってしまいます。

WALとRAID それぞれの有用性は?

―ではWALを格納したディスクをRAIDで冗長化したらいかがですか?

綱川

それも1つの有効な方法です。
WALはメディアリカバリにもクラッシュリカバリにも非常に重要なものです。そのためPostgreSQLコミュニティでは、RAID 1ディスクにWALを配置することが推奨されています。PostgreSQL利用者の中には、実際にそうしている方もいらっしゃいます。
ただし、RAIDを使うとなると最低3台のディスクが必要になります。WALとその他のデータファイルを配置するRAID 1ディスク用に2台と、バックアップ格納用に1台です。さらに、ハードウェアRAIDを使用するとなると専用のハードウェアも必要になります。OSが備えるソフトウェアRAIDであれば特別なハードウェアは不要ですが、ソフトウェアRAIDの構成と管理が追加で必要です。

―管理する対象が増えるので煩雑さが増すということですね。WALの二重化機能の方が管理も容易なのですか?

綱川

そうですね。WALの二重化機能の場合はディスク2台で実現できます。
せっかくバックアップ用のディスクがあるのだから、リカバリーに必要なもののひとつとして二重化WALもそこに配置すれば良いと考えました。バックアップ用ディスクにはリカバリーに必要なものが全て揃っているという分かり易い構成です。
また、RAIDとは異なり利用者が追加作業を行う必要がありません。データベース管理者は、サーバ設定ファイル"postgresql.conf"のbackup_destinationパラメーターにバックアップの場所を設定するだけです。
指定した場所にはデータファイルや設定ファイル、アーカイブWALや二重化WALなどリカバリーに必要なもの全てが自動的に蓄積されます。

―コストパフォーマンスと高い信頼性を両立できるのですね。では、WALの二重化機能があればWALを格納したディスクをRAIDで冗長化することは不要ですか?

綱川

いいえ、RAIDは可用性のためにとても有用です。
先ほどお話ししたとおりWALへの書き込みが失敗するとデータベースは停止してしまいます。RAID1を使えば一方のディスクが故障しても、もう一方のディスクに正常に書き込みができれば業務は継続します。
RAIDとWALの二重化機能を組み合わせれば、RAIDを構成するディスクがすべて故障した場合であっても、バックアップ用ディスクのデータを使って最新状態まで容易にリカバリーできます。

―RAIDとWALの二重化機能を組み合わせることで、より信頼性を高められるのですね。WALの二重化の背景や目的が良く分かりました。

次ページ:WALの二重化機能によるオーバーヘッドの影響は?

  • 1
  • 2

次へarrow-double


本ページに記載された内容は、掲載日現在のものです。その後予告なしに変更されることがあります。あらかじめご了承ください。

富士通のPostgreSQLに関する情報がここに「PostgreSQL インサイド」

製品情報

本コンテンツに関するお問い合わせ

Webでのお問い合わせ

入力フォームはこちらから

当社はセキュリティ保護の観点からSSL技術を使用しております。

お電話でのお問い合わせ

富士通コンタクトライン(総合窓口)0120-933-200

受付時間 9時~17時30分
(土曜・日曜・祝日・当社指定の休業日を除く)