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

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

リレーログファイルはバイナリログファイルと同じ形式で、mysqlbinlog を使用して読み取ることができます (セクション4.6.8「mysqlbinlog — バイナリログファイルを処理するためのユーティリティー」を参照)。 バイナリログのトランザクション圧縮 (MySQL 8.0.20 の時点で使用可能) が使用されている場合、リレーログに書き込まれるトランザクションペイロードはバイナリログと同じ方法で圧縮されます。 バイナリログのトランザクション圧縮の詳細は、セクション5.4.4.5「バイナリログトランザクション圧縮」 を参照してください。

デフォルトのレプリケーションチャネルの場合、リレーログファイル名のデフォルト形式は host_name-relay-bin.nnnnnn です。ここで、host_name はレプリカサーバーホストの名前、nnnnnn はシーケンス番号です。 連続するリレーログファイルは、000001 で始まる連続シーケンス番号を使用して作成されます。 デフォルト以外のレプリケーションチャネルの場合、デフォルトのベース名は host_name-relay-bin-channel です。ここで、channel はリレーログに記録されたレプリケーションチャネルの名前です。

レプリカはインデックスファイルを使用して、現在使用されているリレーログファイルを追跡します。 デフォルトのリレーログインデックスファイル名は、デフォルトチャネルの場合は host_name-relay-bin.index、デフォルト以外のレプリケーションチャネルの場合は host_name-relay-bin-channel.index です。

デフォルトのリレーログファイルとリレーログインデックスファイルの名前と場所は、それぞれ relay_log および relay_log_index システム変数でオーバーライドできます (セクション17.1.6「レプリケーションおよびバイナリロギングのオプションと変数」 を参照)。

レプリカがデフォルトのホストベースのリレーログファイル名を使用する場合、レプリケーションの設定後にレプリカホスト名を変更すると、「リレーログのオープンに失敗しました」および「リレーログの初期化中にターゲットログが見つかりませんでした」のエラーでレプリケーションが失敗する可能性があります。 これは既知の問題です (Bug #2122 を参照してください)。 将来レプリカホスト名が変更される可能性があると予想される場合 (たとえば、DHCP を使用してホスト名を変更できるようにレプリカにネットワーキングが設定されている場合)、レプリカの初期設定時に relay_log および relay_log_index システム変数を使用してリレーログファイル名を明示的に指定することで、この問題を完全に回避できます。 これにより、名前はサーバーのホスト名の変更とは無関係になります。

レプリケーションの開始後に問題が発生した場合に対処するには、レプリカサーバーを停止し、古いリレーログインデックスファイルの内容を新しいファイルの先頭に追加してからレプリカを再起動します。 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

複製サーバーは、次の条件下で新しいリレーログファイルを作成します:

レプリケーション SQL スレッドは、ファイル内のすべてのイベントを実行し、不要になったあと、各リレーログファイルを自動的に削除します。 レプリケーション SQL スレッドがリレーログを削除するための明示的なメカニズムはありません。 ただし、FLUSH LOGS はリレーログをローテーションするため、レプリケーション SQL スレッドがリレーログを削除するタイミングに影響します。