MySQL NDBクラスタ・レプリケーション: シングルチャネル・レプリケーション (2024/04/18)

https://blogs.oracle.com/mysql/post/mysql-ndb-cluster-replication-singlechannel-replication

投稿者： Magnus Blåudd | MySQL NDB Cluster Team Lead

これは、MySQL NDB Clusterレプリケーションに関するシリーズの2番目の記事であり、冗長性、スケーラビリティーの向上、およびパフォーマンスを備えたより高度な構成を構築するために理解しておく必要がある基本的な概念に焦点を当てています。

MySQL NDBクラスタ・レプリケーションに使用される2つの基本的な論理コンポーネントは次のとおりです。

• NDBで発生したすべての変更のバイナリログを書き込むように構成されているbinlog MySQL Server
• binlog MySQL Serverから変更をフェッチし、それを別のクラスタに適用するレプリカMySQL Server

シングルチャネル・レプリケーションを使用してレプリケートする2つのクラスタの論理ビュー

この図は、シングルチャネル・クラスタ・レプリケーションに必要なコンポーネントの論理ビューを示しています。

1. MySQLクライアントは、MySQLサーバーを使用して、NDBのデータの読取りおよび書込みを行います。
2. binlog MySQL Serverは、NDBの変更をバイナリ・ログに書き込みます。
3. レプリカMySQL Serverは、変更をフェッチして別のクラスタに適用します。
4. 最後に、2番目のクラスタの MySQL Serverは、NDBからデータを読み取ります。

シングルチャネル・レプリケーション設定を使用して、あるクラスタから別のクラスタにデータをレプリケートし、2番目のクラスタのレプリケーション冗長性または更新は1番目のクラスタにレプリケートされません。これは、MySQL NDBクラスタ・レプリケーションの非常に珍しい設定ですが、より高度なレプリケーション設定の基本的な構成要素であるため、理解することが重要です。このようなレプリケーションは、データをスタンドアロンのMySQL ServerまたはMySQL Heatwaveにレプリケートする必要がある場合(たとえば、クラスタを分析問合せからオフロードする場合)にも使用できます。

バイナリログの冗長性は、クラスタ間でデータをレプリケートするために必要な論理コンポーネントを示すのみであるため、示されている設定にはありません。高可用性セットアップでは、バイナリログの冗長性、それを実現する方法は、将来の記事で説明します。

binlog MySQL Serverの動作

binlog MySQL Serverは、NDBクラスタで発生した変更をバイナリログに書き込むために使用されます。この機能は MySQL Serverに組み込まれており、--NDB-log-binを使用してオンにできます。これにより、バイナリログに記録されるNDB内のすべてのテーブルにサブスクリプションが設定され、データが変更されると、MySQL Serverはその変更を説明するイベントを取得します。これらの変更イベントは、バイナリログ内のトランザクションとして書き込まれ、各トランザクションは、エポック中に発生したすべての変更を表します。エポックは、NDBで一緒にコミットされたトランザクションをグループ化するために使用されるメカニズムであり、デフォルト設定では、エポックは100ミリ秒ごとにNDBで完了するため、各バイナリログトランザクションはその期間中のすべての変更にまたがります。通常、これらのトランザクションは多くのクライアントからの変更から構成される大規模なトランザクションであり、これは、各クライアントセッションのトランザクションが個別にビンログされる通常の MySQL Serverと大きく異なります。

通常、NDBからのこれらのバイナリログトランザクションをエポックトランザクションと呼び、それらのトランザクションは、変更が発生したNDBクラスタ内で一意の増え続けるエポック番号で識別されます。エポック番号は、mysql.ndb_apply_statusシステム表の更新を追加することで、バイナリログ・トランザクションの一部として保持されます。バイナリログ・トランザクションが後でレプリカ・クラスタに書き込まれると、mysql.ndb_apply_status表が更新され、ソース・クラスタからのレプリケーションの正確な状態が一意に識別されます。バイナリログ・トランザクションには、MySQLサーバーserver_idも含まれているため、変更が発生したソース・クラスタを識別できます。

NDBおよびmysql.ndb_apply_status行からのエポック・トランザクションを含むバイナリ・ログ

トランザクションをバイナリ・ログに書き込む以外に、システム表mysql.ndb_binlog_indexは、エポック番号、server_id、および対応するバイナリログ・ファイル名と位置を含む新しい行で更新されます。この表は、進行状況の監視や、バイナリログ内のエポック・トランザクションがどこにあるかの検索に使用できます。バイナリログ内の正確なポイントからレプリケーションを再起動する必要がある場合には、後者が使用されます。

推奨されるベストプラクティスは、専用のbinlog MySQL Serverを使用することです。このMySQL Serverの機能は、バイナリログの書込みのみであるため、次のことができます。

• タスクに対して最適に構成
• 適切な環境で実行
• あらゆるクライアント負荷によって干渉から保護
• リソースを適切に使用するために監視

データ変更率がそれほど高くないクラスタでは、クライアントによって使用されるサーバーの1つでもバイナリログを書き込むことができます。ただし、特にインスタンスの作成および管理が簡略化されている最新のクラウド環境では、これは推奨されるベストプラクティスではありません。

レプリカのMySQL Serverの動作

レプリカMySQL Serverは、binlog MySQL Serverへの接続、新しいデータ変更のフェッチ、およびNDBへの適用を担当します。これは、通常のCHANGE REPLICATION SOURCE ..コマンドで構成されており、binlog MySQL Serverへの接続方法と、レプリケートを開始するバイナリログ内の場所を指定します。構成後、START REPLICAおよびSTOP REPLICAコマンドは、レプリケーション・チャネルを介したデータのフローを開始または停止します。レプリカMySQL Serverは、レプリケーション・チャネルを介してソースMySQL Serverからバイナリログ・エントリをフェッチします。新しいトランザクションを受け取るたびに、NDBに適用されます。エポック・トランザクション・サイズが大きいと、NDBに大量の操作を送信できるため、トランザクションの適用に必要なラウンドトリップ数が効果的に減少します。NDBは、バッチまたは全体のいずれかでトランザクションを受信すると、使用可能なすべてのデータ・ノードを使用してパラレルに処理されるため、使用可能なリソースが効果的に使用されます。これにより、適用時間が短縮されます。

前述のように、バイナリログ・トランザクションには、レプリカ・クラスタに存在するこの表を更新するmysql.ndb_apply_status表の更新が含まれています。したがって、この行は、トランザクションがコミットされたときと同じソース・クラスタの正確な状態と、エポック・トランザクションを書き込んだbinlog MySQL Serverのserver_idを示します。したがって、この情報は、ソースからレプリカ・クラスタへのレプリケーションの状態を原子的に記録します。エポック番号は、バイナリログの冗長性を使用するときに、別のbinlog MySQL Serverからレプリケーションを再開するためにも使用されます。

異なる機能上の懸念の分離

この記事全体を通してわかるように、それぞれがレプリケーションの独自の部分を処理する2つの異なる論理関数があります。これらの異なる関数は、すべて MySQL Serverに組み込まれており、単一の MySQL Serverインスタンスを使用してシステムを構成しようとする場合がありますが、これらの関数を独自のインスタンスで分離しておくことをお勧めします。もう1つの機能部分は、フロントエンドの読取り/書込みMySQLサーバーです。これは、レプリケーションを処理するMySQLサーバーとは別に水平にスケーリングできる必要があります。NDBに接続されているMySQLサーバーの最大数は250であるため、これらのいくつかをbinlogまたはレプリカMySQL Serverとして機能させることで、クラスタ内に十分な数のMySQLサーバーを保持できます。

最初のクラスタの複数の読取り/書込みMySQLサーバーからの変更が、シングルチャネル・レプリケーションを使用してどのようにレプリケートされるかを示す論理ビュー。

まとめ

この記事では、よく知られ、実証されたMySQLテクノロジを使用して、あるクラスタから別のクラスタにデータをレプリケートする方法について説明します。これを実現する2つの基本的なコンポーネントは、MySQL Serverのbinlogおよびreplicaです。このMySQL Serverには、MySQL NDBクラスタを操作するための拡張機能が含まれています。

詳細情報

レプリケーションの構成方法の詳細は、次を参照してください。

• MySQL Docs - MySQL NDB Cluster replication
• MySQL Docs - MySQL NDB Cluster Single channel replication
• MySQL Docs - MySQL replication

MySQL NDBクラスタはオープンソースであり、ソース形式とバイナリ形式の両方でダウンロードできます。MySQL Community Downloadsでは、GAバージョン8.0とイノベーション・リリースの両方を見つけることができます。

ソース・コードは、GitHubのMySQL Serverリポジトリでも入手でき、高度な高パフォーマンスの分散データベースの内部詳細を調査する際に、大学によって頻繁に使用されます。ソースを自分で探索し、機能強化でプル・リクエストを送信しない理由を探ってください。