データベースレプリケーションのガイド

繰り返しますが、毎回新しい方法で-この芸術ではありませんか？



スタニスラフ・ジャージー・レク、「UncombedThoughts」という本から

辞書では、レプリケーションを2つ（またはそれ以上）のデータセットを一貫した状態に維持するプロセスとして定義しています。「データセットの一貫性のある状態」とは別の大きな問題なので、より簡単な方法で定義を再定式化しましょう。マスターと呼ばれる別のデータセットの変更に応じて、レプリカと呼ばれる1つのデータセットを変更するプロセスです。セットは必ずしも同じではありません。







データベースレプリケーションのサポートは、管理者の最も重要なタスクの1つです。重要なほとんどすべてのデータベースには、レプリカがあります。



レプリケーションタスクには、少なくとも

• メインデータベースが失われた場合のバックアップデータベースのサポート。
• リクエストの一部をレプリカに転送することによるベースの負荷を軽減します。
• アーカイブまたは分析システムへのデータの転送。

この記事では、レプリケーションのタイプと、各タイプのレプリケーションが解決するタスクについて説明します。



レプリケーションには3つのアプローチがあります。

• ストレージシステムレベルでレプリケーションをブロックします。
• DBMSレベルでの物理的な複製。
• DBMSレベルでの論理レプリケーション。

複製をブロックする

ブロックレプリケーションでは、各書き込み操作はプライマリディスクだけでなく、バ​​ックアップでも実行されます。したがって、あるアレイのボリュームは別のアレイのミラーボリュームに対応し、メインボリュームをバイト精度で繰り返します。







このようなレプリケーションの利点には、セットアップの容易さと信頼性が含まれます。データは、ディスクアレイ、またはホストとディスクの間の何か（デバイスまたはソフトウェア）のいずれかによってリモートディスクに書き込むことができます。



ディスクアレイには、レプリケーションを有効にするオプションを追加できます。オプション名は、アレイの製造元によって異なります。





ディスクアレイがデータを複製できない場合は、ホストとアレイの間にエージェントをインストールして、2つのアレイに同時に書き込むことができます。エージェントは、スタンドアロンデバイス（EMC VPLEX）またはソフトウェアコンポーネント（HPE PeerPersistence、Windows Server Storage Replica、DRBD）のいずれかです。同じアレイ、または少なくとも同じメーカーのアレイでのみ機能するディスクアレイとは異なり、エージェントは完全に異なるディスクデバイスで機能します。



ブロックレプリケーションの主な目的は、フォールトトレランスを提供することです。データベースが失われた場合は、ミラーリングされたボリュームを使用してデータベースを再起動できます。



ブロックレプリケーションはその汎用性に優れていますが、汎用性には代償が伴います。



まず、サーバーはミラーリングされたボリュームを処理できません。これは、そのオペレーティングシステムがサーバーへの書き込みを制御できないためです。オブザーバーの観点からは、ミラーリングされたボリューム上のデータはそれ自体で表示されます。障害（プライマリサーバーまたはプライマリサーバーが配置されているデータセンター全体の障害）が発生した場合は、レプリケーションを停止し、プライマリボリュームをアンマウントして、ミラーリングされたボリュームをマウントする必要があります。できるだけ早く、反対方向にレプリケーションを再開する必要があります。



エージェントを使用する場合、これらのアクションはすべてエージェントによって実行されます。これにより、構成が簡素化されますが、切り替え時間は短縮されません。



次に、スタンバイサーバー上のDBMS自体は、ディスクがマウントされた後にのみ起動できます。一部のオペレーティングシステム、たとえばSolarisでは、キャッシュのメモリは割り当て中にマークアップされ、マーク時間は割り当てられたメモリの量に比例します。つまり、インスタンスの開始は瞬時には行われません。さらに、再起動後、キャッシュは空になります。



第3に、バックアップサーバーで起動した後、DBMSはディスク上のデータに一貫性がないことを検出し、REDOログを使用して回復するのにかなりの時間を費やす必要があります。最初に、結果がログに保存されたがデータファイルに保存する時間がなかったトランザクションを繰り返します。次に、障害発生時に完了する時間がなかったトランザクションをロールバックします。



ブロックレプリケーションは負荷分散には使用できません。同様のスキームを使用して、プライマリと同じアレイ上のミラーリングされたボリュームでデータストアをアップグレードします。 EMCとHPはこのスキームをBCVと呼び、EMCのみがBusiness Continuance Volumeを表し、HPはBusiness CopyVolumeを表します。 IBMには、この場合の特別な商標はありません。このスキームは「ミラーボリューム」と呼ばれます。







アレイに2つのボリュームが作成され、書き込み操作は両方で同期的に実行されます（A）。ある時点で、ミラーが壊れます（B）。つまり、ボリュームが独立します。ミラーリングされたボリュームは、ストレージのアップグレード専用のサーバーにマウントされ、そのサーバーでデータベースインスタンスが生成されます。インスタンスは、ブロックレプリケーションの復元の場合と同じくらい時間がかかりますが、オフピーク時にミラーを解除することで、この時間を大幅に短縮できます。重要なのは、その結果としてミラーを壊すことは、DBMSの異常終了と同等であり、異常終了の場合の回復時間は、クラッシュ時のアクティブなトランザクションの数に大きく依存するということです。アンロード用のデータベースは、読み取りと書き込みの両方で使用できます。すべてのブロック識別子、メインボリュームとミラーリングされたボリュームの両方で、休憩後に変更されたミラーは、ブロック変更追跡の特別な領域-BCTに保存されます。



アップロードの終了後、ミラーリングされたボリュームがアンマウントされ（C）、ミラーが復元され、しばらくすると、ミラーリングされたボリュームが再びメインボリュームに追いつき、そのコピーになります。

物理的な複製

ログ（やり直しログまたは先読みログ）には、データベースファイルに加えられたすべての変更が含まれます。物理レプリケーションの背後にある考え方は、ログからの変更が別のデータベース（レプリカ）に再コミットされるため、レプリカ内のデータがメインデータベース内のデータをバイトごとにレプリケートするというものです。



データベースログを使用してレプリカを更新する機能は、1996年にリリースされたOracle 7.3のリリースで登場し、すでにOracle 8iのリリースでは、メインデータベースからレプリカへのログの配信が自動化され、DataGuardと名付けられました。このテクノロジーは非常に需要が高いことが判明したため、今日、物理レプリケーションのメカニズムはほとんどすべての最新のDBMSに存在しています。





経験によれば、サーバーを使用してレプリカを最新の状態に保つだけの場合、メインベースが実行されているサーバーの処理能力の約10％で十分です。



DBMSログは、このプラットフォームの外部で使用することを目的としていません。その形式は文書化されておらず、予告なしに変更される場合があります。したがって、物理的な複製が同じDBMSの同じバージョンのインスタンス間でのみ可能であるという非常に自然な要件。したがって、オペレーティングシステムとプロセッサアーキテクチャに制限があり、ログの形式にも影響を与える可能性があります。



当然、物理レプリケーションはストレージモデルに制限を課しません。さらに、レプリカデータベース内のファイルは、ソースデータベース内とはまったく異なる方法で配置できます。これらのファイルが配置されているボリューム間の対応を記述する必要があるだけです。



Oracle DataGuardを使用すると、レプリカデータベースから一部のファイルを削除できます。この場合、これらのファイルに関連するログの変更は無視されます。



物理データベースレプリケーションには、ストレージレプリケーションに比べて多くの利点があります。

• ログのみが転送され、データファイルは転送されないため、転送されるデータの量は少なくなります。実験では、トラフィックが5〜7倍減少することが示されています。
• : - , ; , ;
• , . , .

レプリカからデータを読み取る機能は、DataGuardテクノロジの名前に「アクティブ」という文字が追加されていることからわかるように、Oracle11gのリリースとともに2007年に導入されました。他のDBMSにもレプリカから読み取る機能がありますが、これは名前には反映されていません。



変更はバイトごとに行われ、レプリカは要求の同時実行を提供できないため、レプリカにデータを書き込むことは不可能です。最近のリリースのOracleActive DataGuardではレプリカへの書き込みが可能ですが、これは「砂糖」にすぎません。実際、変更はメインベースで実行され、クライアントはそれらがレプリカにロールされるのを待っています。



メインデータベース内のファイルが破損している場合は、対応するファイルをレプリカからコピーするだけです（データベースでこれを行う前に、管理者マニュアルを注意深く読んでください！）。レプリカ上のファイルは、メインデータベース内のファイルと同一ではない場合があります。実際、ファイルが展開されると、速度を上げるために新しいブロックには何も入力されず、その内容は偶発的です。ベースはブロック内のすべてのスペースを使用するわけではありませんが（たとえば、ブロック内に空きスペースがある場合）、使用されるスペースの内容は最大バイトに一致します。



物理的な複製は、同期または非同期のいずれかになります。非同期レプリケーションでは、メインベースで完了したが、まだスタンバイベースに到達していない特定のトランザクションのセットが常に存在し、メインベースに障害が発生した場合にスタンバイベースに移行した場合、これらのトランザクションは失われます。同期レプリケーションでは、コミット操作の完了は、このトランザクションに関連するすべてのログレコードがレプリカにコミットされたことを意味します。ログレプリカを取得しても、変更がデータに適用されるわけではないことを理解することが重要です。メインデータベースが失われた場合、トランザクションは失われませんが、アプリケーションがメインデータベースにデータを書き込み、レプリカから読み取る場合、このデータの古いバージョンを取得する可能性があります。



PostgreSQLでは、変更がレプリカデータに適用された後にのみコミットが完了するようにレプリケーションを構成できますが（オプションsynchronous_commit = remote_apply）、Oracleでは、レプリカ全体または個々のセッションを構成して、レプリカがメインデータベースに遅れをとらない場合にのみクエリが実行されるようにすることができます（STANDBY_MAX_DATA_DELAY=0）。ただし、メインデータベースへの書き込みとレプリカからの読み取りが異なるモジュールで実行されるようにアプリケーションを設計することをお勧めします。



同期または非同期のどちらのモードを選択するかという質問に対する答えを探すとき、Oracleのマーケティング担当者が私たちの助けになります。DataGuardは3つのモードを提供し、それぞれが他のパラメーターを犠牲にして、パラメーターの1つ（データの安全性、パフォーマンス、可用性）を最大化します。

• 最大のパフォーマンス：レプリケーションは常に非同期です。
• Maximum protection: ; , commit ;
• Maximum availability: ; , , , .

ブロックレプリケーションに対するデータベースレプリケーションの否定できない利点にもかかわらず、多くの企業、特に信頼性の古い伝統を持つ管理者は、ブロックレプリケーションを放棄することに依然として非常に消極的です。これには2つの理由があります。



まず、ディスクアレイを使用したレプリケーションの場合、トラフィックはデータ伝送ネットワーク（LAN）を通過せず、ストレージエリアネットワークを通過します。多くの場合、はるか昔に構築されたインフラストラクチャでは、SANはデータネットワークよりもはるかに信頼性が高く、効率的です。



第二に、DBMSによる同期レプリケーションは比較的最近信頼できるものになりました。Oracleでは、2007年にリリースされた11gリリースでブレークスルーが発生し、他のDBMSでは、同期レプリケーションがさらに遅れて登場しました。もちろん、情報技術分野の基準による10年はそれほど短くはありませんが、データの安全性に関しては、一部の管理者は依然として「何が起こっても」の原則に導かれています...

論理レプリケーション

データベース内のすべての変更は、APIの呼び出しの結果として発生します。たとえば、SQLクエリの実行の結果として発生します。2つの異なるベースで同じクエリシーケンスを実行するというアイデアは非常に魅力的です。レプリケーションについて従うべき2つのルールがあります。

1. , , . D, A B.
2. , , . B , , C.

コマンドのレプリケーション（ステートメントベースのレプリケーション）は、たとえばMySQLで実装されます。残念ながら、この単純なスキームでは、2つの理由で同一のデータセットが作成されません。



まず、すべてのAPIが決定論的であるとは限りません。たとえば、SQLクエリに現在の時刻を返すnow（）またはsysdate（）関数が含まれている場合、クエリは同時に実行されないため、異なるサーバーで異なる結果が返されます。さらに、トリガーと保存された関数のさまざまな状態、並べ替え順序に影響を与えるさまざまなロケールなど、さまざまなことが違いを引き起こす可能性があります。



次に、並列コマンドベースのレプリケーションを一時停止して正常に再開することはできません。







時間T1で複製が停止した場合、トランザクションBを中止してロールバックする必要があります。レプリケーションを再開すると、トランザクションBの実行により、レプリカがソースデータベースの状態とは異なる状態になる可能性があります。ソースでは、トランザクションAが終了する前にトランザクションBが開始されました。つまり、トランザクションAによって行われた変更は表示されませんでした。

リクエストのレプリケーションを停止して、データベースにアクティブなトランザクションがない時間T2でのみ再起動されます。もちろん、負荷の高い産業基盤にはそのような瞬間はありません。



通常、論理レプリケーションは決定論的クエリを使用します。リクエストの決定性は、次の2つのプロパティによって提供されます。

• クエリは単一のレコードを更新（または挿入または削除）し、そのプライマリ（または一意の）キーで識別します。
• すべてのリクエストパラメータは、リクエスト自体に明示的に設定されます。

ステートメントベースのレプリケーションとは異なり、このアプローチは行ベースのレプリケーションと呼ばれます。



次のデータを含むemployeeテーブルがあるとします。





このテーブルに対して次の操作が実行されました。

update employee set salary = salary*1.2 where dept=36;

データを正しく複製するために、次のクエリがレプリカで実行されます。

update employee set salary = 2160 where id=3817;
update employee set salary = 1920 where id=2274;

クエリは元のベースと同じ結果を生成しますが、実行されたクエリと同等ではありません。



レプリカベースは開いており、読み取りだけでなく書き込みにも使用できます。これにより、レプリカを使用して、追加のテーブルまたはインデックスの作成を必要とするレポートの作成など、クエリの一部を実行できます。



論理レプリカは、追加の変更が行われない場合にのみ、元のベースと同等になることを理解することが重要です。たとえば、上記の例で、レプリカでシドロフの部門が36に追加された場合、彼は昇進を受け取りません。イワノフが部門36から転送された場合、彼は何があっても昇進を受け取ります。



論理レプリケーションは、他のタイプのレプリケーションにはない多くの機能を提供します。

• レプリケートされたデータのセットをテーブルレベルで設定します（物理レプリケーションの場合-ファイルおよびテーブルスペースレベルで、ブロックレプリケーションの場合-ボリュームレベルで）。
• 複雑なレプリケーショントポロジの構築-たとえば、複数のデータベースを1つまたは双方向のレプリケーションに統合します。
• 送信データ量の減少。
• 異なるバージョンのDBMS間、または異なるメーカーのDBMS間での複製。
• 再構築、強化、履歴保存など、複製中のデータ処理。

論理レプリケーションが物理レプリケーションに取って代わることができないという欠点もあります。

• 複製されたすべてのデータにはプライマリキーが必要です。
• 論理レプリケーションはすべてのデータタイプをサポートしているわけではありません。たとえば、BLOBに問題がある可能性があります。
• : , ;
• ;
• , , – , .

最後の2つの欠点は、障害耐性ツールとしての論理レプリカの使用を大幅に制限します。メインデータベースの1つのクエリが一度に多くの行を変更すると、レプリカが大幅に遅れる可能性があります。また、役割を変更するには、開発者と管理者の両方の多大な努力が必要です。



論理レプリケーションを実装するにはいくつかの方法があり、これらの各メソッドは機能の一部を実装し、他の部分は実装しません。

• トリガーによる複製。
• DBMSログの使用。
• CDC（変更データキャプチャ）ソフトウェアの使用。
• 適用されたレプリケーション。

レプリケーションをトリガーする

トリガーは、データを変更するアクションが発生すると自動的に実行されるストアドプロシージャです。各レコードが変更されたときに呼び出されるトリガーは、そのレコードのキー、および古いフィールド値と新しいフィールド値にアクセスできます。必要に応じて、トリガーは新しい行の値を特別なテーブルに保存し、そこからレプリカ側の特別なプロセスがそれらを読み取ります。トリガー内のコードの量が多いため、そのようなトリガーを生成する特別なソフトウェアがあります。たとえば、「マージレプリケーション」（Microsoft SQL Serverのコンポーネント）またはSlony-I（PostgreSQLレプリケーション用の別個の製品）などです。



トリガーレプリケーションの長所：

• メインベースとレプリカのバージョンからの独立性。
• 広範なデータ変換機能。

短所：

• メインベースに負荷をかけます。
• 高いレプリケーションレイテンシ。

DBMSログの使用

DBMS自体も、論理レプリケーション機能を提供できます。ログは、物理的な複製の場合と同様に、データのソースです。バイト変更に関する情報は、変更されたフィールド（Oracle、wal_level = logicalPostgreSQLの補足ロギング）に関する情報、および変更されていない場合でも一意のキーの値にも追加されます。その結果、データベースログの量は増加しています-さまざまな見積もりによると、10％から15％になっています。



レプリケーション機能は、特定のDBMSでの実装によって異なります。Oracleで論理スタンバイを構築できる場合は、PostgreSQLまたはMicrosoft SQL Serverで、組み込みのプラットフォームツールを使用して、相互サブスクリプションとパブリケーションの複雑なシステムを展開できます。さらに、DBMSは、レプリケーションの組み込みの監視と制御を提供します。



このアプローチの欠点には、ログの量の増加とノード間のトラフィックの増加の可能性が含まれます。

CDCの使用

論理レプリケーションを整理するように設計されたソフトウェアのクラス全体があります。このソフトウェアはCDCと呼ばれ、データキャプチャを変更します。このクラスで最も有名なプラットフォームのリストは次のとおりです。

• Oracle GoldenGate（2009年にGoldenGateに買収）。
• IBM InfoSphere Data Replication（以前のInfoSphere CDC、さらに以前は、2007年にDataMirrorによって買収されたDataMirror Transformation Server）。
• VisionSolutions DoubleTake / MIMIX（以前のVision Replicate1）;
• Qlik Data Integration Platform（以前のAttunity）;
• Informatica PowerExchange CDC;
• デベジウム;
• StreamSetsデータコレクタ..。

プラットフォームのタスクは、データベースログを読み取り、情報を変換し、情報をレプリカに転送して適用することです。DBMS自体を使用したレプリケーションの場合と同様に、ログには変更されたフィールドに関する情報が含まれている必要があります。追加のアプリケーションを使用すると、複製されたデータの複雑な変換をその場で実行し、かなり複雑な複製トポロジを構築できます。



強み：

• レポートシステムへのデータのロードを含む、異なるDBMS間で複製する機能。
• データ処理と変換の最も広い可能性。
• ノード間の最小限のトラフィック-プラットフォームは不要なデータを遮断し、トラフィックを圧縮できます。
• レプリケーションのステータスを監視するための組み込み機能。

多くの欠点はありません：

• DBMSによる論理レプリケーションと同様に、ログの量が増加します。
• 新しいソフトウェアの構成や高価なライセンスでは困難です。

これは、企業のデータウェアハウスをほぼリアルタイムで更新するために従来から使用されているCDCプラットフォームです。

応用複製

最後に、複製の別の方法は、クライアント側で直接変更ベクトルを形成することです。クライアントは、単一のレコードに影響を与える決定論的クエリを発行する必要があります。これは、Borland Database Engine（BDE）やHibernateORMなどの特別なデータベースライブラリを使用して実現できます。







アプリケーションがトランザクションを完了すると、Hibernate ORMプラグインは変更ベクトルをキューに書き込み、データベースでトランザクションを実行します。特別なレプリケータプロセスがキューからベクトルを減算し、レプリカベースでトランザクションを実行します。

このメカニズムは、レポートシステムの更新に適しています。フォールトトレランスを提供するためにも使用できますが、この場合、アプリケーションはレプリケーション状態の制御を実装する必要があります。



伝統的に-このアプローチの長所と短所：

• レポートシステムへのデータのロードを含む、異なるDBMS間で複製する機能。
• データを処理および変換する機能、状態の監視など。
• ノード間の最小限のトラフィック-プラットフォームは不要なデータを遮断し、トラフィックを圧縮できます。
• データベースからの完全な独立-フォーマットと内部メカニズムの両方から。

この方法の利点は否定できませんが、2つの非常に深刻な欠点があります。

• アプリケーションアーキテクチャの制限。
• 大量のネイティブレプリケーションコード。

では、どちらが良いですか？

他の多くの人のように、この質問に対する明確な答えはありません。ただし、以下の表が、特定のタスクごとに正しい選択を行うのに役立つことを願っています。

• , ; .
• , .
• , .
• .
• , , .
• CDC , / .
• .