ミラーリングするか、しないか、それが問題だ (2021/06/01)

https://blogs.oracle.com/maa/to-mirror-or-not-to-mirror-thats-the-question

投稿者：Pieter Van Puymbroeck | Product Manager (Active) Data Guard and Flashback

この質問は、しばしば別の質問から始まります。"どうすれば、データ損失をゼロにし、ダウンタイムを最小限に抑えて、データベースを保護することができますか？どのようなインフラで運用されているかに関わらず、これは非常に良い、一般的で有効な質問です。

データベースの規模が大きくなればなるほど、ソリューションはより創造的になり、その創造性には複雑さとトレードオフが伴います。しかし、適切なディザスタリカバリを実現する唯一の方法は、データを少なくとも1つの他の物理的なサイトに複製することです。これは広く受け入れられている答えであり、シンプルに聞こえますよね？

AからBにデータを転送する方法はいくつかありますが、ここからが面白いところです。ソフトウェアをもっと単純な例に例えると、ネジで視覚化することができます。壁にネジを刺すのにハンマーは使いませんよね？ねじを傷つけてしまうか、意図したようにきれいに壁にねじを打ち込むことができずに壁を傷つけてしまうかのどちらかです。最終的にはうまくいくでしょうが、この作業にはハンマーよりもドライバーの方が適していることは間違いありません。

ソフトウェアにも同じ原則があります。仕事に適したツールを使うことです。

ここでは、Oracle Databaseの適切な保護に焦点を移しましょう。サードパーティのアプリケーションはさておき、このブログ記事では、ストレージレプリケーションと、この技術をOracle Databaseに使用したときに何が起こるのか、あるいは起こりうるのかに焦点を当てます。

ストレージレプリケーション技術の内部を見ると、「書き込まれたものは、宛先側にも書き込まれる必要がある」という非常にシンプルな原則を使用していることを理解する必要があります。これは非常に堅実でシンプルな原則だと思いますよね？そうではありません。もしその1回の書き込みでデータベースが壊れてしまったら？メカニズムはそのブロック内で何が起こっているかを知らず、喜んでデスティネーションにも送ります。つまり、その時点で、両方のサイトで同じ破損が発生するため、スタンバイサイトを失ってしまうのです。最近のシステムでは、書き込みがシステムから2回発行されるため（アレイAに1回、アレイBに1回）、エラーになりにくいというのがよく使われる議論です。しかし...もし、書き込みによって論理的にデータベースが破損したらどうでしょうか？両方のサイトが再び使えなくなり、手遅れになるまで気づかないことが多いのです。

つまり、ブロックの破損は検出できないが、ストレージのレプリケーションでデータベースを保護できるということですね？しかし、実際にはそうではありません。例えば、誤ってファイルを削除してしまったらどうでしょう？その削除が複製され、リモートサイトでもファイルが失われ、同じような悲惨な状況になってしまいます。スタンバイを使用する可能性のあるユースケースを拡大すると、さらに良くなりません。

レプリケーションが行われている間に、読み取り専用の分析クエリやレポートをリモートサイトにオフロードしたい場合はどうでしょうか？ミラーリングされたコピーはこのような用途には使用できません。つまり、ワークロードをオフロードする技術を失うだけでなく、そうすることで得られるスタンバイ環境の継続的な運用検証も失うことになります。このように、ストレージレプリケーションはデータを忠実にコピーしますが、あらゆる種類の破損も忠実にコピーしてしまい、最悪の場合、ミラーサイトが使えなくなってしまうということがわかりますね。

それは今でも続いています。先日、ヨーロッパに200以上の実店舗と約3万人の従業員を抱える大手小売企業の会議に参加するよう依頼されました。彼らはディザスターリカバリープランに関する深刻な問題に直面していました。このような場合、私は喜んで手を貸し、ガイダンスを提供します。その結果、正しく設定され、十分に調整されたストレージレプリケーションシステムが問題に直面していることがわかりました。すべてのシステムは仮想化されており、Oracle Databaseを内蔵したボックスから稼働していました。ある時点で、プライマリストレージアレイがコールドシャットダウンに直面しました。そして、すべてのVMがここで稼働していることに気づいたとき、これは深刻な問題となりました。さらに悪いことに ターゲットシステムへの書き込みがすべて完了しなかったのです。これにより、環境の約75％が完全に使用できなくなりました。問題はエスカレートし、非本番環境全体をバックアップからリストアする必要があり、本番システムから新たなクローンを作成する必要がありました。幸運なことに、本番環境の書き込みは時間内に完了し、これらの環境は反対側で再び開くことができました。完全なリストア作業には10日以上かかりました。本番システムにも影響が及んでいたら、どうなっていたか想像してみてください。

これは最近のケースであり、ストレージベンダーに承認された、正しくチューニングされ構成されたシステムからのものである。良かれと思ってした予防措置にもかかわらず、このような現実のストレージ複製による災害が、現代のディザスタリカバリ構成で起こりうると安心できるでしょうか？頻繁に起こるものでしょうか？いいえ、このような大規模な災害と同様に、稀なことではありますが、実際に起こっています。

ねじの話を覚えていますか？Oracle Databaseを保護するためには、もっと優れたツールがあります。それがOracle Active Data Guardです。

MAAの重要なテクノロジーであるOracle Data Guardは、シンプルな原理で動作します。それは、REDO と呼ばれるデータベーストランザクションによって行われたすべての変更を使用することです。Data Guard は、「REDO を出荷してから、REDO を適用する」という最も単純な原則を採用しています。Redo には、Oracle Databaseがデータベース トランザクションを回復するために必要なすべての情報が含まれます。プライマリ データベースと呼ばれる本番データベースは、REDO を 1 つ以上の独立したレプリカ （スタンバイ データベースと呼ばれる）に送信します。Oracle Active Data Guard のスタンバイ データベースは、継続的にリカバリの状態にあり、プライマリ データベースとの同期を維持するために REDO の検証と適用を行います。この検証は、Data Guardでのみ行うことができます。ブロックに何が必要なのかは、データベースだけが知っています。このようにして、スタンバイデータベースに送られるデータが完全に正しいことを保証することができます。

また、Oracle Data Guard は、ネットワークやスタンバイの停止によりプライマリデータベースとの接続が一時的に切断されたスタンバイデータベースを自動的に再同期します。

こうすることで、I/Oレイヤーをバイパスし、ブロックの破損がターゲットの宛先に送られるリスクを低減します。さらに、データベース・トランザクションが多くのブロックに触れる場合、ストレージ・ミラーリングはそれらすべてのブロックを複製します。OracleのオンラインREDOログといえば、常に変化していることを思い出すでしょう! REDOの発生率が高い環境を想像してみてください。それらのブロックはすべてもう一方のボックスに配信されますが、リカバリーには必要ありません。したがって、これは単なるオーバーヘッドです。

Oracle Data Guardのレプリケーションは、転送するデータ量を大幅に削減するだけでなく、転送前にブロックが論理的に正しいかどうかを検証します。また、データはリモートサイトでも検証されます。

Oracle Data Guardは、Oracle Enterprise Editionに含まれており、スタンバイデータベースの作成と管理、役割の移行（スイッチオーバーとフェイルオーバー）の実行、スタンバイを使ったスナップショット・スタンバイモードでのリード/ライトテスト、さらにはFast-startフェイルオーバーによる自動化されたフェイルオーバーなど、Data Guardのすべての機能を提供します。これは、ストレージミラーリングだけでは実現できないことです。

スタンバイデータベースを読み取り専用で開き、その間にすべてのREDOが到着して適用されることが可能です。このリモートサイトでの読み取り専用機能、および Oracle Data Guard のその他の機能には、Oracle Active Data Guard オプションが必要です。この Active Data Guard ライセンスでは、バックアップやローリングアップグレードなどの運用作業の負荷を軽減するために、スタンバイデータベースをより便利にする追加機能が提供されます。これらの機能の好例が、19cの新機能であるDMLリダイレクションです。これにより、読み取り専用のスタンバイ・データベースに対して臨時のDMLを実行することができます。この機能については以前ブログで紹介しました。

もうお分かりだと思いますが、Oracle Active Data Guardは、Oracle Databaseに保存されている大切なデータを完全に保護する仕事に適した唯一のツールであり、本稿で取り上げたように、このアプローチがストレージレベルのレプリケーションと比較してOracle Databaseの保護に優れているのはそのためです。 レポート

For more details, refer to:
Oracle.com/goto/dataguard
Oracle.com/goto/maa
You can also follow me on Twitter at @VanPupi or Oracle MAA at @OracleMAA for new updates.