このセクションでは、単一のレプリケーションチャネルを使用して NDB Cluster レプリケーションを開始する手順の概要を示します。
-
次のコマンドを発行して、MySQL レプリケーションソースサーバーを起動します:
shellS> mysqld --ndbcluster --server-id=id \ --log-bin --ndb-log-bin &前述のステートメントで、
idはこのサーバーの一意の ID です (セクション23.6.2「NDB Cluster レプリケーションの一般的な要件」 を参照)。 これにより、適切なロギング形式を使用してバイナリロギングを有効にして、サーバー mysqld プロセスが開始されます。 NDB 8.0 では、--ndb-log-binオプションを使用してNDBテーブルへの更新のロギングを明示的に有効にすることも必要です。これは NDB Cluster の以前のバージョンからの変更であり、このオプションはデフォルトで有効になっていました。注記--binlog-format=MIXEDを使用してソースを起動することもできます。この場合、クラスタ間のレプリケート時に行ベースのレプリケーションが自動的に使用されます。 ステートメントベースのバイナリロギングは NDB Cluster レプリケーションではサポートされていません (セクション23.6.2「NDB Cluster レプリケーションの一般的な要件」 を参照)。 -
次に示すように、MySQL レプリカサーバーを起動します:
shellR> mysqld --ndbcluster --server-id=id &前述のコマンドで、
idはレプリカサーバーの一意の ID です。 レプリカでロギングを有効にする必要はありません。注記このコマンドで
--skip-slave-startオプションを使用するか、レプリケーションをすぐに開始しないかぎり、skip-slave-startをレプリカサーバーのmy.cnfファイルに含める必要があります。 このオプションを使用すると、次のステップ 4 で説明するように、適切なSTART REPLICA | SLAVEステートメントが発行されるまでレプリケーションの開始が遅延されます。 -
レプリカサーバーをソースサーバーのレプリケーションバイナリログと同期化する必要があります。 バイナリロギングがソースで以前に実行されていない場合は、レプリカで次のステートメントを実行します:
mysqlR> CHANGE MASTER TO -> MASTER_LOG_FILE='', -> MASTER_LOG_POS=4; Or from MySQL 8.0.23: mysqlR> CHANGE REPLICATION SOURCE TO -> SOURCE_LOG_FILE='', -> SOURCE_LOG_POS=4;これにより、レプリカはログの開始点からソースサーバーのバイナリログの読取りを開始するように指示されます。 その他:バックアップを使用してソースからデータをロードする場合。このような場合に
MASTER_LOG_FILEおよびMASTER_LOG_POSに使用する正しい値を取得する方法の詳細は、セクション23.6.8「NDB Cluster レプリケーションによるフェイルオーバーの実装」 を参照してください。 -
最後に、レプリカ上の mysql クライアントから次のコマンドを発行して、レプリケーションの適用を開始するようにレプリカに指示します:
mysqlR> START SLAVE; Or from MySQL 8.0.22: mysqlR> START REPLICA;これにより、ソースからレプリカへのデータおよび変更の転送も開始されます。
次のセクションで説明する手順に類似した方法で、2 つのレプリケーションチャネルを使用することも可能です。この方法と 1 つのレプリケーションチャネルを使用する方法との違いはセクション23.6.7「NDB Cluster レプリケーションでの 2 つのレプリケーションチャネルの使用」で説明しています。
バッチ更新を有効にして、クラスタのレプリケーションのパフォーマンスを向上することも可能です。 これを行うには、レプリカ mysqld プロセスで slave_allow_batching システム変数を設定します。 通常、更新は受け取るとすぐに適用されます。 ただし、バッチ処理を使用すると、それぞれ 32 KB のバッチで更新が適用されます。特に個々の更新が比較的小さい場合、スループットが高くなり、CPU 使用率が低下する可能性があります。
バッチ処理はエポック単位で機能します。複数のトランザクションに属する更新は、同じバッチの一部として送信できます。
すべての未処理の更新は、その更新の合計が 32K バイト未満であっても、エポックの最後に達したときに適用されます。
バッチ処理は、実行時にオンとオフを切り替えることができます。 実行時にこれを有効にするため、次の 2 つのステートメントのどちらかを使用できます。
SET GLOBAL slave_allow_batching = 1;
SET GLOBAL slave_allow_batching = ON;特定のバッチによって問題が発生した場合 (効果が正しくレプリケートされていないように見えるステートメントなど)、次のいずれかのステートメントを使用してバッチ処理を非アクティブ化できます:
SET GLOBAL slave_allow_batching = 0;
SET GLOBAL slave_allow_batching = OFF;
次のように、適切な SHOW VARIABLES ステートメントを使用して、バッチ処理が現在使用されているかどうかを確認できます:
mysql> SHOW VARIABLES LIKE 'slave%';
+---------------------------+-------+
| Variable_name | Value |
+---------------------------+-------+
| slave_allow_batching | ON |
| slave_compressed_protocol | OFF |
| slave_load_tmpdir | /tmp |
| slave_net_timeout | 3600 |
| slave_skip_errors | OFF |
| slave_transaction_retries | 10 |
+---------------------------+-------+
6 rows in set (0.00 sec)