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

このセクションでは、単一のレプリケーションチャネルを使用して 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)