1. Oracle以外のデータベースのためのOracle GoldenGate Classic Architectureの使用
  2. Oracle GoldenGate for MySQLの使用
  3. MySQL Group Replicationを利用するOracle GoldenGateの使用

15 MySQL Group Replicationを利用するOracle GoldenGateの使用

このトピックでは、MySQL Group ReplicationをサポートするようにOracle GoldenGateを設定するための要件および構成ステップについて説明します。

内容は次のとおりです。

親トピック: Oracle GoldenGate for MySQLの使用

MySQL Group ReplicationをサポートするOracle GoldenGateの機能

次に、MySQLデータベース・グループ・レプリケーション・インスタンスからのキャプチャをサポートするために必要なOracle GoldenGateの機能を示します。

CSN形式

MySQL Group ReplicationのExtractでは、グループ・レプリケーション・グローバル・トランザクションIDに基づく新しいCSN形式を使用します。ソース証跡がMySQL Group Replication Extractによって生成されたMySQL Group Replication ExtractまたはReplicatを手動で位置指定する場合は、このCSN形式でATCSNおよびAFTERCSNを使用する必要があります。

グループ・レプリケーションのキャプチャで使用される順序の例を次に示します。
00000000000000000001:f77024f9-f4e3-11eb-a052-0021f6e03f10:0000000000000010654

この順序では、Oracle GoldenGateの順序番号は00000000000000000001で、GTIDはf77024f9-f4e3-11eb-a052-0021f6e03f10:0000000000000010654です。

拡張チェックポイントのサポート

MySQL Group ReplicationのExtractには、コアExtractチェックポイント・ファイルの他に拡張チェックポイント・ファイルが含まれています。拡張チェックポイント・ファイルは、コア・チェックポイントと同じチェックポイント・ディレクトリに作成され、キャプチャ・グループの名前の後にcpex拡張子が付きます(例: extmysql.cpex)。

このファイルは、Extractの起動時に作成され、Extractの削除時に削除されるため、編集しないでください。

GTIDベースのExtractの使用
gtid_modeがMySQLデータベースで有効になっている場合、Oracle GoldenGate Extract for MySQLは、GTIDベースのリカバリ・メカニズムおよび拡張チェックポイントを使用して自動的に開始されるため、フェイルオーバーおよびリカバリをサポートできます。Extractに追加のパラメータは必要ありません。

ノート:

グループ・レプリケーションを使用しない場合は、ソースMySQLデータベースでgtid_modeを無効にすることをお薦めします。これにより、Extractのキャプチャ動作がログ番号およびオフセット方法を使用するように返されます。

親トピック: MySQL Group Replicationを利用するOracle GoldenGateの使用

グループ・レプリケーションをサポートするための要件

このトピックでは、MySQL Group Replicationを利用するOracle GoldenGateデータベース・クラスタを使用するための要件について説明します。

  • MySQL Group ReplicationのためのOracle GoldenGateは、MySQLバージョン8.0以上をサポートしており、Oracle GoldenGateバージョン21.7以上が必要です。

  • Extractでは、単一プライマリ・モードで構成されたグループ・レプリケーションのみがサポートされます。

  • MySQLデータベース設定gtid_modeを有効にする必要があります。

トピック:

親トピック: MySQL Group Replicationを利用するOracle GoldenGateの使用

Oracle GoldenGate for MySQLでのグループ・レプリケーションの制限

Oracle GoldenGate for MySQLでMySQL Group Replicationを使用する場合は、次のサポート制限が適用されます。

  • マルチプライマリ・モード用に構成されたグループ・レプリケーションはサポートされていません。

  • MySQL Group Replicationインスタンスに対して構成されている場合、Extractはリモート証跡も複数のローカル証跡もサポートしません。リモート証跡を使用する必要がある場合は、データ・ポンプを使用してClassic Architectureで証跡を送信できます。Microservices Architectureでは、DISTPATHを使用して証跡を転送します。分散パスの管理を参照してください。

  • グループ・レプリケーション用に構成されたデータベースに対してExtractが実行されている場合、ログ番号およびオフセットによる位置指定はサポートされません。

親トピック: グループ・レプリケーションをサポートするための要件

グループ・レプリケーション・クラスタのSSL構成

グループ・レプリケーション・クラスタでのSSL構成について学習します。

内容は次のとおりです。

親トピック: MySQL Group Replicationを利用するOracle GoldenGateの使用

グループ・レプリケーションのためのデータベース・クラスタSSL構成の概要

クラスタ化されたデータベース環境には、1つのプライマリ・ノードと1つ以上のセカンダリ・ノードを構成する様々なノードが含まれています。一度に1つのプライマリ・ノードのみが存在できます。各ノードには、固有のホスト名とMySQLデータベース・インスタンスがあり、その特定のノードの個別の構成によって維持されます。クラスタ内のすべてのノードは、総合してデータベースを表します。

また、データベースに接続しようとするクライアントの最初の連絡先であるルーターもあります。

SSL接続を有効にする場合、すべてのデータベース・ノードとルーターに独自の承認キーとサーバー証明書が必要です。これらの証明書は、共通認証局(CA)によって承認される必要があります。

この設定で一般的に使用される証明書は次のとおりです。

  • CA.pem: 共通CA (認証局)の証明書

  • server-cert.pem: データベース・ノードを識別するためにCAによって認証された証明書

  • server-key.pem: 個々のデータベース・ノードの秘密キー

  • router-cert.pem: ルーターを識別するためにCAによって認証された証明書

  • router-key.pem: ルーターの秘密キー

ルーターおよびデータベース・ノードの構成について、次の表で説明します。この説明のために、次の例では1つのルーターと3つのデータベース・ノードを示しています。

表15-1 ルーターおよびデータベース・ノードの構成

ルーター -

ホスト名

mysqlrouter.company.com

構成ファイル名

mysqlrouter.conf

ポート

6446

共通名

mysqlrouter.company.com

証明書名

server-cert.pem

キー・ファイル名

server-key.pem

データベース・ノード1

-

ホスト名

dbnode1.company.com

構成ファイル名

my.cnf

ポート

3308

共通名

dbnode1

証明書名

server-cert.pem

キー・ファイル名

server-key.pem

ノード・ランク

プライマリ

データベース・ノード2

-

ホスト名

dbnode2.company.com

構成ファイル名

my.cnf

ポート

3308

共通名

dbnode2

証明書名

server-cert.pem

キー・ファイル名

server-key.pem

ノード・ランク

セカンダリ

データベース・ノード3

-

ホスト名

dbnode3.company.com

構成ファイル名

my.cnf

ポート

3308

共通名

dbnode3

証明書名

server-cert.pem

キー・ファイル名

server-key.pem

ノード・ランク

セカンダリ

親トピック: グループ・レプリケーション・クラスタのSSL構成

サーバー証明書の作成

ルーターおよびデータベース・ノードの構成を開始する前に、SSLサーバー証明書を作成する必要があります。SSLを使用してデータベース・ノードおよびルーターを接続するには、セキュアな通信のために適切なSSLキーおよび証明書が必要です。すべての証明書は、共通認証局(CA)によって認識される必要があります。データベース/ルーターのインストール中にキーおよび証明書が自動生成された場合(または自己署名の場合)は、接続が失敗する可能性があります。続行できるのは、CAによって承認された証明書のみです。

承認されたサーバー・キーおよび証明書がすでに使用可能な場合は、証明書に正しい権限があり、ルーター/データベース・ノードの正しいパスに配置されていることを確認します。

サーバーのSSL証明書を生成するステップは、次を参照してください。

OpenSSLを使用したSSL証明書およびキーの作成

SSL証明書を構成するためのタスク

  1. データベース・ノードごとに個別の証明書とキーを生成します。

  2. すべてのデータベース・ノードおよびルーターに共通する同じca.pemを使用します。

  3. データベース・ノードのサーバー証明書には、ドメイン名なしで共通名を指定します。詳細は、「グループ・レプリケーションのためのデータベース・クラスタSSL構成の概要」の表15-1の共通名を参照してください。

  4. サーバーの証明書名およびキー・ファイル名が、対応するデータベース・ノードおよびルーターの値と一致していることを確認します。

  5. 生成された各サーバー証明書のCN値を検証するには、次のコマンドを使用してopenSSLを起動します。
    openssl x509 -text -in ca.pem
openssl x509 -text -in server-cert.pem
openssl x509 -text -in client-cert.pem

    発行者CNは、すべて同じである必要があります。サブジェクトCNには、ドメイン名のないホスト名のみを指定する必要があります。

  6. 証明書を生成した後、CAファイルと照合して検証します。

  7. 生成された証明書およびキー・ファイルを、各データベース・ノードおよびルーターのMySQLデータ・ディレクトリにコピーします。すべてのユーザーに読取り権限を付与し、ファイル所有者のみに書込み権限を確保していることを確認してください。

  8. 共通ca.pemをすべてのノードおよびルーターにコピーし、すべてのユーザーに読取り権限を付与します。

親トピック: グループ・レプリケーション・クラスタのSSL構成

データベース・ノードおよびルーターの構成

次のような設定を使用して、セキュアなSSL接続を介して接続するためのデータベース・ノードおよびルーターを構成します。
ルーター

ルーター構成ファイルで、次の設定が存在することを確認します。

CLIENT_SSL_MODE=PREFERRED
CLIENT_SSL_CERT=absolute path of the generated router certificate
CLIENT_SSL_KEY=absolute path of the generated router key
SERVER_SSL_MODE=AS_CLIENT
SERVER_SSL_VERIFY=VERIFY_IDENTITY
SERVER_SSL_CA=absolute path of the common ca.pem placed on this server

構成後、すべてのユーザーに読取り権限を付与し、グループおよびその他のユーザーからの書込み権限を取り消します。

データベース・ノード
各MySQLデータベース・ノードで、適切なセクションに次の設定が指定されていることを確認します。
SSL_CAPATH=absolute path of the common ca.pem placed on this node
SSL_CA=ca.pem
SSL_CERT=server-cert.pem
SSL_KEY=server-key.pem
GROUP_REPLICATION_SSL_MODE=REQUIRED
REQUIRE_SECURE_TRANSPORT=ON

データベース・ノードを構成した後、すべてのユーザーに読取り権限を付与し、グループおよびその他のユーザーからの書込み権限を取り消します。

接続のテスト

構成が実施され、適切な権限が構成ファイルに付与されたら、データベース・ノードおよびルーターを再起動して設定をテストします。

データベース・ノード接続のテスト
データベース・ノードが終了していないことを確認します。構成ファイルのlog-error設定の下にあるログで、SSL設定が受け入れられなかったことを示すエラーまたは警告がないか確認してください。次のコマンド・ラインを使用して特定のノードに接続してみます(このノードの証明書に指定されている共通名を使用します)。
mysql -u username -p password -h db_common_name -P db_port --ssl-mode=VERIFY_IDENTITY --ssl-ca=path/of/ca.pem

接続でエラーが生成されないことを確認します。

同様に、適切なパラメータ値を指定して、様々なSSLモードで接続します。

ノート:

VERIFY_IDENTITYには、ssl-certおよびssl-keyは必須ではありません。ただし、データベース・ユーザーがX509認証を必要とする場合は、ssl-certとssl-keyの両方をclient-certとclient-keyで指定する必要があります。

この方法を使用してすべてのデータベース・ノードをテストしてから、ルーター接続をテストします。

ルーター接続のテスト

データベース・ノードが起動したら、ルーターを再起動し、終了しないように監視します。

構成ファイルのlog-error設定の下にあるログで、SSL設定が受け入れられなかったことを示すエラーまたは警告がないか確認してください。エラーや警告がない場合は、次のコマンドを使用して、ルーターからデータベースへの接続を試みます。ルーターの証明書に指定されている共通名を使用していることを確認します。
mysql -u username -p password -h router_common_name -P router_port --ssl-mode=VERIFY_IDENTITY --ssl-ca=path/of/ca.pem

接続がエラーなしで完了することを確認します。

ルーターからデータベース・ノードへの接続の確認
最初に、次のコマンドを使用して、現在アクティブなプライマリ・ノードを特定します。
MySQL> SHOW VARIABLES like '%hosts%';
次に、データベースからログアウトし、データベースを別のノードに切り替えます。さらに、次のコマンドを使用して、ルーターからデータベースに再度ログインします。
mysql -u username -p password -h router_common_name -P router_port --ssl-mode=VERIFY_IDENTITY --ssl-ca=path/of/ca.pem

同じコマンドを再度使用して、現在アクティブなプライマリ・ノードを確認します。

MySQL> SHOW VARIABLES like '%hosts%';

親トピック: グループ・レプリケーション・クラスタのSSL構成