各レプリカには、server_id システム変数で指定された一意のサーバー ID が必要です。 複数のレプリカを設定する場合、各レプリカの server_id 値は、ソースと他のレプリカの値とは異なる一意である必要があります。 レプリカサーバー ID がまだ設定されていない場合、または現在の値がソースまたは別のレプリカに選択した値と競合する場合は、それを変更する必要があります。

デフォルトの server_id 値は 1 です。 次のようなステートメントを発行して、server_id 値を動的に変更できます:

SET GLOBAL server_id = 21;

サーバー ID の値が 0 の場合、レプリカはソースに接続できません。 そのサーバー ID 値 (以前のリリースではデフォルト) が以前に設定されていた場合は、サーバーを再起動して、新しいゼロ以外のサーバー ID でレプリカを初期化する必要があります。 それ以外の場合は、サーバー ID を変更するときにサーバーを再起動する必要はありません。ただし、サーバー ID を必要とする他の構成を変更する場合は除きます。 たとえば、バイナリロギングがサーバーで無効になっていて、それをレプリカに対して有効にする場合、これを有効にするにはサーバーの再起動が必要です。

レプリカサーバーを停止する場合は、構成ファイルの[mysqld]セクションを編集して、一意のサーバー ID を指定できます。 例:

[mysqld]
server-id=21

バイナリロギングは、すべてのサーバーでデフォルトで有効になっています。 レプリケーションを実行するために、レプリカでバイナリロギングを有効にする必要はありません。 ただし、レプリカのバイナリロギングとは、レプリカバイナリログをデータバックアップおよびクラッシュ回復に使用できることを意味します。 バイナリロギングが有効になっているレプリカは、より複雑なレプリケーショントポロジの一部としても使用できます。 たとえば、次の連鎖配置を使用してレプリケーションサーバーを設定できます:

A -> B -> C

ここで、A はレプリカ B のソースとして機能し、B はレプリカ C のソースとして機能します。 これが機能するには、B がソースとレプリカの両方である必要があります。 A から受信した更新を C に渡すには、B がバイナリログに記録する必要があります。 バイナリロギングに加えて、このレプリケーショントポロジでは log_slave_updates システム変数を有効にする必要があります。 レプリカ更新が有効になっている場合、レプリカはソースから受信し、レプリカ SQL スレッドによって実行された更新をレプリカ独自のバイナリログに書き込みます。 log_slave_updates システム変数はデフォルトで有効になっています。

レプリカでバイナリロギングまたはレプリカ更新ロギングを無効にする必要がある場合は、レプリカの --skip-log-bin および --log-slave-updates=OFF オプションを指定することでこれを行うことができます。 レプリカでこれらの機能を再度有効にする場合は、関連するオプションを削除してサーバーを再起動します。