Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 26.8Mb
PDF (A4) - 26.9Mb
HTML Download (TGZ) - 7.1Mb
HTML Download (Zip) - 7.2Mb


MySQL 5.6 リファレンスマニュアル  /  ...  /  MySQL Cluster レプリケーションの起動 (レプリケーションチャネルが 1 つ)

18.6.6 MySQL Cluster レプリケーションの起動 (レプリケーションチャネルが 1 つ)

このセクションでは、1 つのレプリケーションチャネルを使用する MySQL Cluster レプリケーションを起動するための手順の概要について説明します。

  1. このコマンドを発行して MySQL レプリケーションのマスターサーバーを起動します。

    shellM> mysqld --ndbcluster --server-id=id \
            --log-bin &

    前のステートメントで、id はこのサーバーの一意の ID です (セクション18.6.2「MySQL Cluster レプリケーションの一般要件」を参照してください)。これは、適切なロギング形式を使用するバイナリロギングを有効にして、サーバーの mysqld プロセスを起動します。

    注記

    --binlog-format=MIXED でマスターを起動することもできます。この場合、クラスタ間で複製するときに行ベースのレプリケーションが自動的に使用されます。STATEMENT ベースのバイナリロギングは MySQL Cluster レプリケーションではサポートされていません (セクション18.6.2「MySQL Cluster レプリケーションの一般要件」を参照してください)。

  2. ここで示すように、MySQL レプリケーションのスレーブサーバーを起動します。

    shellS> mysqld --ndbcluster --server-id=id &

    ここで示すコマンドで、id はスレーブサーバーの一意の ID です。レプリケーションスレーブでロギングを有効にする必要はありません。

    注記

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

  3. マスターサーバーのレプリケーションバイナリログとスレーブサーバーとの同期を取る必要があります。これまでにマスターでバイナリロギングが実行していなかった場合、次のステートメントをスレーブで実行します。

    mysqlS> CHANGE MASTER TO
         -> MASTER_LOG_FILE='',
         -> MASTER_LOG_POS=4;

    これは、ログの開始ポイントからマスターのバイナリログを読み取るようにスレーブに指示します。ほかの方法で、つまり、バックアップを使用してマスターからデータをロードする場合、MASTER_LOG_FILE および MASTER_LOG_POS に使用する適切な値を取得する方法について、セクション18.6.8「MySQL Cluster レプリケーションを使用したフェイルオーバーの実装」を参照してください。

  4. 最後に、レプリケーションスレーブで mysql クライアントからこのコマンドを発行して、レプリケーションの適用を開始するようにスレーブに指示する必要があります。

    mysqlS> START SLAVE;

    これにより、レプリケーションデータのマスターからスレーブへの転送も開始します。

次のセクションで説明する手順に類似した方法で、2 つのレプリケーションチャネルを使用することも可能です。この方法と 1 つのレプリケーションチャネルを使用する方法との違いはセクション18.6.7「2 つのレプリケーションチャネルを使用する MySQL Cluster レプリケーション」で説明しています。

バッチ更新を有効にして、クラスタのレプリケーションのパフォーマンスを向上することも可能です。スレーブの mysqld プロセスで slave_allow_batching システム変数を設定することで、これを実現できます。通常、更新は受け取るとすぐに適用されます。しかし、バッチを使用すると、更新は 32K バイトがまとめて適用されるため、特に個々の更新が比較的小さい場合、スループットは向上しますが、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)

User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
Sign Up Login You must be logged in to post a comment.