このページは機械翻訳したものです。

23.6.6 NDB Cluster レプリケーションの開始 (シングルレプリケーションチャネル)

このセクションでは、単一のレプリケーションチャネルを使用して NDB Cluster レプリケーションを開始する手順の概要を示します。

1. 次のコマンドを発行して、MySQL レプリケーションソースサーバーを起動します:

   Press CTRL+C to copy
    
   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 レプリケーションの一般的な要件」 を参照)。

2. 次に示すように、MySQL レプリカサーバーを起動します:

   Press CTRL+C to copy
    
   shellR> mysqld --ndbcluster --server-id=id &

   前述のコマンドで、id はレプリカサーバーの一意の ID です。 レプリカでロギングを有効にする必要はありません。

   注記

   このコマンドで --skip-slave-start オプションを使用するか、レプリケーションをすぐに開始しないかぎり、skip-slave-start をレプリカサーバーの my.cnf ファイルに含める必要があります。 このオプションを使用すると、次のステップ 4 で説明するように、適切な START REPLICA | SLAVE ステートメントが発行されるまでレプリケーションの開始が遅延されます。

3. レプリカサーバーをソースサーバーのレプリケーションバイナリログと同期化する必要があります。 バイナリロギングがソースで以前に実行されていない場合は、レプリカで次のステートメントを実行します:

   Press CTRL+C to copy
    
   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 レプリケーションによるフェイルオーバーの実装」 を参照してください。

4. 最後に、レプリカ上の mysql クライアントから次のコマンドを発行して、レプリケーションの適用を開始するようにレプリカに指示します:

   Press CTRL+C to copy
    
   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 つのステートメントのどちらかを使用できます。

Press CTRL+C to copy
 
SET GLOBAL slave_allow_batching = 1;
SET GLOBAL slave_allow_batching = ON;

特定のバッチによって問題が発生した場合 (効果が正しくレプリケートされていないように見えるステートメントなど)、次のいずれかのステートメントを使用してバッチ処理を非アクティブ化できます:

Press CTRL+C to copy
 
SET GLOBAL slave_allow_batching = 0;
SET GLOBAL slave_allow_batching = OFF;

次のように、適切な SHOW VARIABLES ステートメントを使用して、バッチ処理が現在使用されているかどうかを確認できます:

Press CTRL+C to copy
 
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)