データベースの高可用性の比較-MySQL/MariaDBレプリケーションとOracleDataGuard

「StateoftheOpen-Source DBMS Market、2018」では、Gartnerは、2022年までに新しい社内アプリケーションの70％がオープンソースデータベースで開発されると予測しています。また、既存の商用データベースの50％が変換されます。したがって、Oracle DBAは、従来のOracleインスタンスとともに、新しいオープンソースデータベースの展開と管理を開始する準備をします。すでにやっていない限り。

では、MySQLまたはMariaDBレプリケーションはOracle DataGuardに対してどのようにスタックしますか？このブログでは、高可用性データベースソリューションの観点から2つを比較します。

何を探すべきか

最新のデータレプリケーションアーキテクチャは、一方向および双方向のデータレプリケーションを可能にする柔軟な設計に基づいて構築されており、計画外のサービス障害が発生した場合のセカンダリデータベースへの迅速な自動フェイルオーバーも可能です。フェイルオーバーも実行が簡単で信頼性が高いため、コミットされたトランザクションが失われることはありません。さらに、スイッチオーバーまたはフェイルオーバーは、理想的にはアプリケーションに対して透過的である必要があります。

データレプリケーションソリューションは、処理のボトルネックを回避し、データへのリアルタイムアクセスを保証するために、非常に低いレイテンシでデータをコピーできる必要があります。リアルタイムコピーは、低コストのハードウェアで実行されている別のデータベースに展開できます。

ディザスタリカバリに使用する場合は、サービスの中断を最小限に抑えてセカンダリシステムへのアプリケーションアクセスを保証するために、システムを検証する必要があります。理想的なソリューションでは、ディザスタリカバリプロセスの定期的なテストが可能になるはずです。

比較の主なトピック

データの可用性と一貫性
- Gtid、scm
- 複数のスタンバイ、非同期+同期モデルへのレプリケーションについて言及
- 本番環境の障害からのスタンバイの分離（例：mysqlのレプリケーションの遅延）
- データの損失を回避する（同期レプリケーション）
スタンバイシステムの使用率
- スタンバイの使用法
フェイルオーバー、スイッチオーバー、および自動回復
- データベースフェイルオーバー
- 透過的なアプリケーションフェイルオーバー（TAFとProxySQL、MaxScale）
セキュリティ
使いやすさと管理（事前に統合されたコンポーネントの統合管理）

データの可用性と一貫性

MySQL GTID

MySQL 5.5レプリケーションは、バイナリログイベントに基づいていました。スレーブが知っていたのは、正確なイベントと、マスターから読み取った正確な位置だけでした。マスターからの単一のトランザクションは、さまざまなスレーブからのさまざまなバイナリログで終了している可能性があり、トランザクションは通常、これらのログでさまざまな位置にあります。これは制限付きのシンプルなソリューションでした。トポロジを変更すると、管理者が関連するインスタンスのレプリケーションを停止する必要が生じる可能性があります。これらの変更により、他の問題が発生する可能性があります。たとえば、時間のかかる再構築なしでは、スレーブをレプリケーションチェーンの下位に移動できませんでした。壊れたレプリケーションリンクを修正するには、新しいバイナリログファイルとスレーブで実行された最後のトランザクションの位置を手動で決定し、そこから再開するか、完全に再構築する必要があります。グローバルトランザクション識別子を夢見ながら、これらの制限を回避する必要がありました。

MySQLバージョン5.6（およびMariaDBバージョン10.0.2）は、この問題を解決するメカニズムを導入しました。 GTID（Global Transaction Identifier）は、ノード間でより優れたトランザクションマッピングを提供します。

GTIDを使用すると、スレーブは複数のマスターからの一意のトランザクションを確認でき、レプリケーションを再開または再開する必要がある場合は、これをスレーブ実行リストに簡単にマッピングできます。したがって、アドバイスは常にGTIDを使用することです。 MySQLとMariaDBのGTID実装は異なることに注意してください。

Oracle SCN

1992年のリリース7.3で、Oracleは、データベースの同期コピーをスタンバイとして保持するソリューションを導入しました。これは、バージョン9iリリース2のData Guardと呼ばれます。DataGuard構成は、2つの主要コンポーネント、1つのプライマリデータベース、およびスタンバイデータベースで構成されます。（最大30）。プライマリデータベースでの変更はスタンバイデータベースを介して渡され、これらの変更はスタンバイデータベースに適用されて同期が維持されます。

Oracle Data Guardは、最初はプライマリデータベースのバックアップから作成されます。 Data Guardは、プライマリデータベースREDO（トランザクションを保護するためにすべてのOracleデータベースで使用される情報）を送信し、それをスタンバイデータベースに適用することにより、プライマリデータベースとすべてのスタンバイデータベースを自動的に同期します。 Oracleは、SCN（システム変更番号）と呼ばれる内部メカニズムを使用します。システム変更番号（SCN）はOracleの時計であり、コミットするたびに時計が増加します。 SCNは、データベース内の一貫した時点をマークします。これは、ダーティブロック（バッファキャッシュからディスクに変更されたブロック）を書き込む動作であるチェックポイントです。 MySQLのGTIDと比較できます。

Data Guardトランスポート・サービスは、プライマリ・データベースからスタンバイ・データベースへのREDOの送信のすべての側面を処理します。ユーザーがプライマリでトランザクションをコミットすると、REDOレコードが生成され、ローカルのオンラインログファイルに書き込まれます。 Data Guardトランスポート・サービスは、同じREDOをプライマリ・データベース・ログ・バッファー（システム・グローバル領域内に割り当てられたメモリー）からスタンバイ・データベースに直接送信し、スタンバイ・REDOログ・ファイルに書き込まれます。

MySQLレプリケーションとDataGuardにはいくつかの主な違いがあります。 Data Guardのメモリからの直接送信により、プライマリデータベースでのディスクI/Oオーバーヘッドが回避されます。 MySQLの動作とは異なります。メモリからデータを読み取ると、プライマリデータベースのI/Oが減少します。

DataGuardはデータベースREDOのみを送信します。リアルタイムの同期を維持するために、すべてのファイルで変更されたすべてのブロックを送信する必要があるストレージリモートミラーリングとはまったく対照的です。

非同期+同期モデル

Oracle Data Guardは、REDO適用用に3つの異なるモデルを提供しています。利用可能なハードウェア、プロセス、そして最終的にはビジネスニーズに依存する適応モデル。

最大パフォーマンス-デフォルトの操作モード。トランザクションを回復するために必要なREDOデータがマスターのローカルREDOログに書き込まれるとすぐにトランザクションをコミットできます。
最大の保護-データの損失がなく、最大レベルの保護。各操作を改善するために必要なREDOデータは、トランザクションをコミットする前に、マスターのローカルオンラインREDOログと少なくとも1つのスタンバイデータベースのスタンバイREDOログの両方に書き込む必要があります（Oracleでは少なくとも2つのスタンバイを推奨しています）。プライマリデータベースは、障害によってREDOストリームを少なくとも1つの同期スタンバイデータベースに書き込めない場合にシャットダウンします。
最大可用性-最大保護に似ていますが、障害によってREDOストリームの書き込みが妨げられても、プライマリデータベースはシャットダウンされません。

MySQLレプリケーション設定の選択に関しては、非同期レプリケーションまたは準同期レプリケーションのいずれかを選択できます。

非同期binlogapplyは、MySQLレプリケーションのデフォルトの方法です。マスターはイベントをバイナリログに書き込み、スレーブは準備ができたらイベントを要求します。イベントがスレーブに到達するという保証はありません。
プライマリでの準同期コミットは、マスターが準同期スレーブからデータがスレーブによって受信および書き込まれるという確認応答を受信するまで遅延されます。準同期レプリケーションでは、追加のプラグインをインストールする必要があることに注意してください。

スタンバイシステムの使用率

MySQLは、レプリケーションの単純さと柔軟性でよく知られています。デフォルトでは、スタンバイ/スレーブサーバーに対して読み取りまたは書き込みを行うことができます。幸い、MySQL 5.6および5.7は、グローバルトランザクションID、イベントチェックサム、マルチスレッドスレーブ、クラッシュセーフスレーブ/マスターなど、レプリケーションに多くの重要な機能拡張をもたらし、レプリケーションをさらに改善しました。 MySQLレプリケーションの読み取りと書き込みに慣れているDBAは、その兄であるOracleからの同様のまたはさらに単純なソリューションを期待します。残念ながら、デフォルトではありません。

Oracleの標準のフィジカル・スタンバイの実装は、読み取り/書き込み操作のために閉じられています。実際、Oracleは論理的なバリエーションを提供しますが、多くの制限があり、HA用に設計されていません。この問題の解決策は、Active Data Guardと呼ばれる追加の有料機能です。これを使用して、REDOログを適用しながらスタンバイからデータを読み取ることができます。

Active Data Guardは、Oracle Database Enterprise Edition（最高コストのライセンス）でのみ利用可能なOracleの無料のDataGuard災害復旧ソフトウェアに対する有料のアドオンソリューションです。プライマリデータベースから送信された変更を継続的に適用しながら、読み取り専用アクセスを提供します。アクティブなスタンバイデータベースとして、プライマリデータベースから読み取りクエリ、レポート、および増分バックアップをオフロードするのに役立ちます。この製品のアーキテクチャは、プライマリデータベースで発生する可能性のある障害からスタンバイデータベースを分離できるように設計されています。

Oracleデータベース12cのエキサイティングな機能と、Oracle DBAが見逃してしまう機能は、データ破損の検証です。 Oracle Data Guardの破損チェックは、データがスタンバイ・データベースにコピーされる前に、データが正確に整列していることを確認するために実行されます。このメカニズムを使用して、プライマリ上のデータブロックをスタンバイデータベースから直接復元することもできます。

フェイルオーバー、スイッチオーバー、および自動回復

レプリケーションのセットアップを安定して実行し続けるには、システムが障害に対して回復力を持つことが重要です。障害は、ソフトウェアのバグ、構成の問題、またはハードウェアの問題のいずれかが原因で発生し、いつでも発生する可能性があります。サーバーがダウンした場合は、セットアップの劣化に関するアラーム通知が必要です。フェイルオーバー（マスターへのスレーブの昇格）は、昇格するスレーブを決定する必要がある管理者が実行できます。

管理者は、障害、データが失われた場合の同期ステータス、および最後にアクションを実行するための手順に関する情報を必要とします。理想的には、すべてが自動化され、単一のコンソールから表示される必要があります。

MySQLフェイルオーバーには、自動と手動の2つの主要なアプローチがあります。どちらのオプションにもファンがいます。概念については別の記事で説明します。

GTIDを使用すると、手動フェイルオーバーがはるかに簡単になります。次のような手順で構成されています：

レシーバーモジュールを停止します（STOP SLAVE IO_THREAD）
マスターを切り替えます（マスターをに変更します）
レシーバーモジュールを起動します（START SLAVE IO_THREAD）

Oracle Data Guardには、専用のフェイルオーバー/スイッチオーバー・ソリューションであるDataGuardBrokerが付属しています。ブローカは、Oracle Data Guard構成の作成、保守、および監視を自動化および一元化する分散管理フレームワークです。 DGブローカーツールにアクセスすると、構成の変更、スイッチオーバー、フェイルオーバー、さらには高可用性セットアップのドライテストを実行できます。 2つの主なアクションは次のとおりです。

コマンドSWITCHOVERTOは、スイッチオーバー操作を実行するために使用されます。スイッチオーバー操作が成功すると、データベースインスタンスは場所を切り替え、レプリケーションが続行されます。スタンバイが応答していないとき、またはスタンバイがダウンしているときは、切り替えることはできません。
一般的なFAILOVERTO<スタンバイデータベース名>は、フェイルオーバーを実行するために使用されます。フェイルオーバー操作の後、以前のプライマリサーバーは再作成が必要ですが、新しいプライマリはデータベースのワークロードを引き受ける可能性があります。

フェイルオーバーについて言えば、アプリケーションのフェイルオーバーがどれほどシームレスであるかを考慮する必要があります。計画的/計画外の停止が発生した場合、ビジネスの中断を最小限に抑えながら、ユーザーセッションをセカンダリサイトに効率的に誘導できます。

MySQLの標準的なアプローチは、利用可能なロードバランサーの1つを使用することです。 HTTPまたはTCP/IPフェイルオーバーに広く使用されているHAProxyから始まり、データベース対応のMaxscaleまたはProxySQLに移行します。

Oracleでは、この問題はTAF（Transparent Application Failover）によって対処されます。スイッチオーバーまたはフェイルオーバーが発生すると、アプリケーションは自動的に新しいプライマリに転送されます。 TAFを使用すると、接続先のデータベースインスタンスに障害が発生した場合に、アプリケーションが自動的かつ透過的に新しいデータベースに再接続できます。

セキュリティ

最近の多くの組織にとって、データセキュリティはホットな問題です。 PCI DSSやHIPAAなどの標準を実装する必要がある場合は、データベースのセキュリティが必須です。クロスWAN環境では、特に国内および国際的な規制に準拠する必要のある企業が増えるため、データのプライバシーとセキュリティに関する懸念が生じる可能性があります。レプリケーションに使用されるMySQLバイナリログには、読みやすい機密データが含まれている場合があります。標準構成では、データの盗用は非常に簡単なプロセスです。 MySQLは、MySQLサーバー（レプリケーション）間およびMySQLサーバーとクライアント間のトラフィックを暗号化するメカニズムとしてSSLをサポートしています。 SSL暗号化を実装する一般的な方法は、自己署名証明書を使用することです。ほとんどの場合、認証局によって発行されたSSL証明書を取得する必要はありません。以下の例のように、opensslを使用して証明書を作成できます。

$ openssl genrsa 2048 > ca-key.pem
$ openssl req -new -x509 -nodes -days 3600 -key ca-key.pem > ca-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl rsa -in client-key.pem -out client-key.pem
$ openssl rsa -in server-key.pem -out server-key.pem

次に、SSLのパラメータを使用してレプリケーションを変更します。

….MASTER_SSL=1, MASTER_SSL_CA = '/etc/security/ca.pem', MASTER_SSL_CERT = '/etc/security/client-cert.pem', MASTER_SSL_KEY = '/etc/security/client-key.pem';

より自動化されたオプションについては、ClusterControlを使用して暗号化を有効にし、SSLキーを管理できます。

Oracle 12cでは、Data Guard REDOトランスポートを、Oracle Advanced Security（OAS）と呼ばれる一連の専用セキュリティ機能と統合できます。 Advanced Securityを使用して、プライマリシステムとスタンバイシステム間の暗号化および認証サービスを有効にすることができます。たとえば、Advanced Encryption Standard（AES）暗号化アルゴリズムを有効にすると、SQLnet.oraファイルでパラメータをわずかに変更するだけでREDO（MySQL binlogと同様）を暗号化できます。外部証明書のセットアップは必要なく、スタンバイデータベースの再起動のみが必要です。 sqlnet.oraとwalletの変更は次のように簡単です。

ウォレットディレクトリを作成する

mkdir /u01/app/wallet

sqlnet.oraを編集

ENCRYPTION_WALLET_LOCATION=
 (SOURCE=
  (METHOD=file)
   (METHOD_DATA=
    (DIRECTORY=/u01/app/wallet)))

キーストアを作成する

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/wallet' identified by root ;

オープンストア

ADMINISTER KEY MANAGEMENT set KEYSTORE open identified by root ;

マスターキーを作成する

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY root WITH BACKUP;

スタンバイ中

ウォレットディレクトリのp12ファイルと.ssoファイルをコピーし、プライマリノードと同様にsqlnet.oraファイルを更新します。

詳細については、OracleのTDEホワイトペーパーに従ってください。ホワイトペーパーから、データファイルを暗号化してウォレットを常に開いておく方法を学ぶことができます。

使いやすさと管理

Oracle Data Guard構成を管理またはデプロイする場合、検索する手順とパラメータが多数あることに気付く場合があります。これに答えるために、OracleはDGBrokerを作成しました。

DG Brokerを実装しなくても、確かにData Guard構成を作成できますが、それによって生活がはるかに快適になります。実装されると、ブローカーのコマンドラインユーティリティであるDGMGRLがおそらくDBAの主要な選択肢になります。 GUIを好む人のために、Cloud Control 13cには、Webインターフェイスを介してDGBrokerにアクセスするオプションがあります。

Brokerが支援できるタスクは、マネージドリカバリの自動開始、フェイルオーバー/スイッチオーバーのための1つのコマンド、DGレプリケーションの監視、構成の検証などです。

DGMGRL> show configuration 
Configuration - orcl_s9s_config 

Protection Mode: MaxPerformance
  Members:

s9sp  - Primary database
    s9ss - Physical standby database 

Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS   (status updated 12 seconds ago

MySQLは、OracleDGBrokerと同様のソリューションを提供していません。ただし、Orchestrator、MHA、ロードバランサー（ProxySQL、HAProxy、Maxscale）などのツールを使用して機能を拡張できます。データベースとロードバランサーを管理するためのソリューションはClusterControlです。 ClusterControl Enterprise Editionは、無料のCommunity Editionの一部として提供される展開および監視機能に加えて、管理およびスケーリング機能のフルセットを提供します。