17.2.2.1 スレーブリレーログ

リレーログは、バイナリログと同様に、データベース変更を記述するイベントを含む番号付きファイルのセットと、使用されたすべてのリレーログファイルの名前を含むインデックスファイルとで構成されます。

用語「リレーログファイル」は一般的に、データベースイベントを含む個々の番号付きファイルを示します。用語「リレーログ」は、番号付きリレーログファイルとインデックスファイルのセットの総称です。

リレーログファイルはバイナリログファイルと同じ形式で、mysqlbinlog を使用して読み取ることができます (セクション4.6.8「mysqlbinlog — バイナリログファイルを処理するためのユーティリティー」を参照)。

デフォルトでは、データディレクトリ内でのリレーログファイル名の形式は host_name-relay-bin.nnnnnn です。ここで、host_name はスレーブサーバーホストの名前、nnnnnn はシーケンス番号です。連続するリレーログファイルは、000001 で始まる連続シーケンス番号を使用して作成されます。スレーブはインデックスファイルを使用して現在使用中のリレーログファイルを追跡します。データディレクトリ内でのデフォルトのリレーログインデックスファイル名は、host_name-relay-bin.index です。

デフォルトのリレーログファイルおよびリレーログインデックスファイル名はそれぞれ、--relay-log および --relay-log-index サーバーオプションでオーバーライドできます (セクション17.1.4「レプリケーションおよびバイナリロギングのオプションと変数」を参照)。

スレーブがデフォルトのホストベースリレーログファイル名を使用する場合、レプリケーションセットアップ後にスレーブのホスト名を変更すると、レプリケーションが次のエラーで失敗する可能性があります: Failed to open the relay log および Could not find target log during relay log initialization。これは既知の問題です (Bug #2122 を参照してください)。今後スレーブのホスト名が変更される見込みがある場合は (たとえば、DHCP を使用してそのホスト名を変更できるように、スレーブでネットワークがセットアップされている場合)、スレーブを最初にセットアップするときに --relay-log および --relay-log-index オプションを使用してリレーログファイル名を明示的に指定することで、この問題を完全に回避できます。これにより、サーバーホスト名の変更との間に名前の依存関係がなくなります。

レプリケーションがすでに開始されたあとに問題が発生した場合、これを回避する 1 つの方法は、スレーブサーバーを停止し、古いリレーログインデックスファイルの内容を新しいものの前に付加してからスレーブを再起動することです。Unix システムでは、ここで示すようにこれを実行できます。

shell> cat new_relay_log_name.index >> old_relay_log_name.index
shell> mv old_relay_log_name.index new_relay_log_name.index

スレーブサーバーは次の条件で新しいリレーログファイルを作成します。

• I/O スレッドが起動するたび。

• ログがフラッシュされたとき。たとえば、FLUSH LOGS または mysqladmin flush-logs で。

• 現在のリレーログファイルのサイズが「大きくなりすぎた」とき。次のように判断します。

  • max_relay_log_size (最大リレーログファイルサイズ) の値が 0 より大きい場合。

  • max_relay_log_size の値が 0 の場合、max_binlog_size が最大リレーログファイルサイズを判断します。

SQL スレッドは、各リレーログファイル内のすべてのイベントの実行し、それが不要になるとすぐに、ファイルを自動的に削除します。SQL スレッドがこの処理を担当するため、リレーログを削除するための明示的なメカニズムはありません。ただし、FLUSH LOGS はリレーログをローテーションしますが、これは SQL スレッドがいつそれらを削除するかに影響します。