データ移行中継ログ
データ移行 (DM) リレー ログは、データベースの変更を説明するイベントを含む番号付きファイルのいくつかのセットと、使用されたすべてのリレー ログ ファイルの名前を含むインデックス ファイルで構成されます。
リレー ログを有効にすると、DM-worker は自動的にアップストリームの binlog をローカル構成ディレクトリに移行します (DM が TiUP を使用してデプロイされている場合、デフォルトの移行ディレクトリは<deploy_dir>/<relay_log>です)。 <relay_log>のデフォルト値はrelay-dirで、 アップストリーム データベースConfiguration / コンフィグレーションファイルで変更できます。 v5.4.0 以降、 DM-worker 構成ファイルのrelay-dirまでローカル構成ディレクトリを構成できます。これは、アップストリーム データベースの構成ファイルよりも優先されます。
DM-worker が実行されている場合、上流の binlog をリアルタイムでローカル ファイルに移行します。 DM-worker の同期処理ユニットは、ローカル リレー ログの binlog イベントをリアルタイムで読み取り、これらのイベントを SQL ステートメントに変換してから、これらのステートメントを下流のデータベースに移行します。
このドキュメントでは、DM リレー ログのディレクトリ構造と初期移行ルール、およびリレー ログの一時停止、再開、パージの方法について説明します。
ノート：
リレー ログ機能では、追加のディスク I/O 操作が必要になるため、データ移行のレイテンシーが長くなります。展開環境のディスク I/O パフォーマンスが低い場合、リレー ログ機能が移行タスクのボトルネックになり、移行が遅くなる可能性があります。
ディレクトリ構造
リレー ログのローカル ストレージのディレクトリ構造の例:
<deploy_dir>/<relay_log>/
|-- 7e427cc0-091c-11e9-9e45-72b7c59d52d7.000001
| |-- mysql-bin.000001
| |-- mysql-bin.000002
| |-- mysql-bin.000003
| |-- mysql-bin.000004
| `-- relay.meta
|-- 842965eb-091c-11e9-9e45-9a3bff03fa39.000002
| |-- mysql-bin.000001
| `-- relay.meta
`-- server-uuid.index
subdir:DM-worker は、アップストリーム データベースから移行された binlog を同じディレクトリに保存します。各ディレクトリは
subdirです。subdirは<Upstream database UUID>.<Local subdir serial number>という名前です。アップストリームでプライマリ インスタンスとセカンダリ インスタンスを切り替えた後、DM-worker は増分シリアル番号を持つ新しい
subdirディレクトリを生成します。- 上記の例では、
7e427cc0-091c-11e9-9e45-72b7c59d52d7.000001ディレクトリの場合、7e427cc0-091c-11e9-9e45-72b7c59d52d7はアップストリーム データベースの UUID であり、000001はローカルsubdirシリアル番号です。
- 上記の例では、
server-uuid.index: 現在使用可能なsubdirのディレクトリの名前のリストを記録します。relay.meta: 移行された binlog の情報をsubdirごとに格納します。例えば、$ cat c0149e17-dff1-11e8-b6a8-0242ac110004.000001/relay.meta binlog-name = "mysql-bin.000010" # The name of the currently migrated binlog. binlog-pos = 63083620 # The position of the currently migrated binlog. binlog-gtid = "c0149e17-dff1-11e8-b6a8-0242ac110004:1-3328" # GTID of the currently migrated binlog. # There might be multiple GTIDs. $ cat 92acbd8a-c844-11e7-94a1-1866daf8accc.000001/relay.meta binlog-name = "mysql-bin.018393" binlog-pos = 277987307 binlog-gtid = "3ccc475b-2343-11e7-be21-6c0b84d59f30:1-14,406a3f61-690d-11e7-87c5-6c92bf46f384:1-94321383,53bfca22-690d-11e7-8a62-18ded7a37b78:1-495,686e1ab6-c47e-11e7-a42c-6c92bf46f384:1-34981190,03fc0263-28c7-11e7-a653-6c0b84d59f30:1-7041423,05474d3c-28c7-11e7-8352-203db246dd3d:1-170,10b039fc-c843-11e7-8f6a-1866daf8d810:1-308290454"
初期移行ルール
リレー ログの移行の開始位置は、次の規則によって決定されます。
ダウンストリーム同期ユニットのチェックポイントから、DM は最初に、移行タスクがデータ ソースからレプリケートする必要がある最も早い位置を取得します。ポジションが次のいずれかのポジションより遅い場合、DM-worker はこのポジションから移行を開始します。
有効なローカル リレー ログが存在する場合 (有効なリレー ログとは、有効な
server-uuid.index、およびsubdirファイルを含むリレー ログです)、DM-worker はrelay.metaによって記録された位置から移行を再開しrelay.meta。有効なローカル リレー ログが存在しないが、ソース構成ファイルで
relay-binlog-nameまたはrelay-binlog-gtidが指定されている場合:- 非 GTID モードで
relay-binlog-nameを指定すると、DM-worker は指定された binlog ファイルからマイグレーションを開始します。 - GTID モードで
relay-binlog-gtidを指定すると、DM-worker は指定された GTID からマイグレーションを開始します。
- 非 GTID モードで
有効なローカル リレー ログが存在せず、DM 構成ファイルで
relay-binlog-nameまたはrelay-binlog-gtidが指定されていない場合:非 GTID モードでは、DM-worker は最初の上流の binlog から移行を開始し、すべての上流の binlog ファイルを最新のものに順次移行します。
GTID モードでは、DM-worker は最初のアップストリーム GTID から移行を開始します。
ノート：
アップストリーム リレー ログがパージされると、エラーが発生します。この場合、マイグレーションの開始位置を指定するために
relay-binlog-gtidを設定します。
リレーログ機能の開始と停止
- v5.4.0 and later versions
- versions between v2.0.2 (included) and v5.3.0 (included)
- earlier than v2.0.2
v5.4.0 以降のバージョンでは、 enable-relay ～ trueを設定することでリレー ログを有効にできます。 v5.4.0 以降、アップストリーム データ ソースをバインドするときに、DM-worker はデータ ソースの構成のenable-relay項目をチェックします。 enable-relayがtrueの場合、このデータ ソースに対してリレー ログ機能が有効になります。
詳細な設定方法については、 アップストリーム データベースConfiguration / コンフィグレーションファイルを参照してください。
さらに、 start-relayまたはstop-relayコマンドを使用してデータ ソースのenable-relay構成を動的に調整し、リレー ログ イン タイムを有効または無効にすることもできます。
» start-relay -s mysql-replica-01
{
"result": true,
"msg": ""
}
ノート：
DM v2.0.2 より後の DM v2.0.x および v5.3.0 では、ソース構成ファイルの構成項目
enable-relayは無効になり、start-relayとstop-relayのみを使用してリレー ログを有効または無効にできます。 データ ソース構成の読み込みのときにenable-relayがtrueに設定されていることを DM が検出すると、次のメッセージが出力されます。
コマンドstart-relayでは、指定されたデータ ソースのリレー ログを移行するように 1 つ以上の DM-worker を構成できますが、パラメーターで指定された DM-worker は解放されているか、上流のデータ ソースにバインドされている必要があります。例は次のとおりです。
» start-relay -s mysql-replica-01 worker1 worker2
{
"result": true,
"msg": ""
}
» stop-relay -s mysql-replica-01 worker1 worker2
{
"result": true,
"msg": ""
}
v2.0.2 より前の DM バージョン (v2.0.2 を除く) では、DM ワーカーをアップストリーム データ ソースにバインドするときに、DM はソース構成ファイルの構成項目enable-relayをチェックします。 enable-relayがtrueに設定されている場合、DM はデータ ソースのリレー ログ機能を有効にします。
設定項目enable-relayの設定方法はアップストリーム データベースConfiguration / コンフィグレーションファイルを参照してください。
リレー ログのクエリ
コマンドquery-status -sを使用して、アップストリーム データ ソースのリレー ログ プル プロセスのステータスを照会できます。次の例を参照してください。
» query-status -s mysql-replica-01
{
"result": true,
"msg": "",
"sources": [
{
"result": true,
"msg": "no sub task started",
"sourceStatus": {
"source": "mysql-replica-01",
"worker": "worker2",
"result": null,
"relayStatus": {
"masterBinlog": "(mysql-bin.000005, 916)",
"masterBinlogGtid": "09bec856-ba95-11ea-850a-58f2b4af5188:1-28",
"relaySubDir": "09bec856-ba95-11ea-850a-58f2b4af5188.000001",
"relayBinlog": "(mysql-bin.000005, 4)",
"relayBinlogGtid": "09bec856-ba95-11ea-850a-58f2b4af5188:1-28",
"relayCatchUpMaster": false,
"stage": "Running",
"result": null
}
},
"subTaskStatus": [
]
},
{
"result": true,
"msg": "no sub task started",
"sourceStatus": {
"source": "mysql-replica-01",
"worker": "worker1",
"result": null,
"relayStatus": {
"masterBinlog": "(mysql-bin.000005, 916)",
"masterBinlogGtid": "09bec856-ba95-11ea-850a-58f2b4af5188:1-28",
"relaySubDir": "09bec856-ba95-11ea-850a-58f2b4af5188.000001",
"relayBinlog": "(mysql-bin.000005, 916)",
"relayBinlogGtid": "",
"relayCatchUpMaster": true,
"stage": "Running",
"result": null
}
},
"subTaskStatus": [
]
}
]
}
リレー ログ機能の一時停止と再開
コマンドpause-relayを使用してリレー ログのプル プロセスを一時停止し、コマンドresume-relayを使用してプロセスを再開できます。これら 2 つのコマンドを実行するときは、アップストリーム データ ソースのsource-idを指定する必要があります。次の例を参照してください。
» pause-relay -s mysql-replica-01 -s mysql-replica-02
{
"op": "PauseRelay",
"result": true,
"msg": "",
"sources": [
{
"result": true,
"msg": "",
"source": "mysql-replica-01",
"worker": "worker1"
},
{
"result": true,
"msg": "",
"source": "mysql-replica-02",
"worker": "worker2"
}
]
}
» resume-relay -s mysql-replica-01
{
"op": "ResumeRelay",
"result": true,
"msg": "",
"sources": [
{
"result": true,
"msg": "",
"source": "mysql-replica-01",
"worker": "worker1"
}
]
}
リレー ログのパージ
ファイルの読み取りと書き込みの検出メカニズムを通じて、DM-worker は、現在実行中のデータ移行タスクによって使用されている、または後で使用されるリレー ログをパージしません。
中継ログのデータ消去方法には、自動消去と手動消去があります。
自動データ消去
自動データ消去を有効にして、ソース構成ファイルでその戦略を構成できます。次の例を参照してください。
# relay log purge strategy
purge:
interval: 3600
expires: 24
remain-space: 15
purge.interval- バックグラウンドでの自動パージの間隔 (秒単位)。
- デフォルトでは「3600」で、バックグラウンド パージ タスクが 3600 秒ごとに実行されることを示します。
purge.expires- リレー ログ (以前にリレー処理ユニットに書き込まれ、使用されていないか、現在実行中のデータ移行タスクによって後で読み取られることはない) を保持できる時間数。バックグラウンド パージ。
- デフォルトは「0」で、リレーログの更新時刻によるデータパージは行われません。
purge.remain-space- 自動バックグラウンド パージで安全にパージできるリレー ログを、指定された DM ワーカー マシンがパージしようとする、GB 単位の残りのディスク容量。
0に設定すると、残りのディスク容量に応じてデータのパージは実行されません。 - デフォルトの「15」は、使用可能なディスク容量が 15GB 未満になると、DM マスターがリレー ログを安全にパージしようとすることを示します。
- 自動バックグラウンド パージで安全にパージできるリレー ログを、指定された DM ワーカー マシンがパージしようとする、GB 単位の残りのディスク容量。
手動データ消去
手動データ消去とは、dmctl が提供するpurge-relayコマンドを使用してsubdirと binlog 名を指定し、指定された binlogより前のすべてのリレー ログを消去することを意味します。コマンドの-subdirオプションが指定されていない場合、現在のリレー ログ サブディレクトリより前のすべてのリレー ログが消去されます。
現在のリレーログのディレクトリ構造が次のとおりであると仮定します。
$ tree .
.
|-- deb76a2b-09cc-11e9-9129-5242cf3bb246.000001
| |-- mysql-bin.000001
| |-- mysql-bin.000002
| |-- mysql-bin.000003
| `-- relay.meta
|-- deb76a2b-09cc-11e9-9129-5242cf3bb246.000003
| |-- mysql-bin.000001
| `-- relay.meta
|-- e4e0e8ab-09cc-11e9-9220-82cc35207219.000002
| |-- mysql-bin.000001
| `-- relay.meta
`-- server-uuid.index
$ cat server-uuid.index
deb76a2b-09cc-11e9-9129-5242cf3bb246.000001
e4e0e8ab-09cc-11e9-9220-82cc35207219.000002
deb76a2b-09cc-11e9-9129-5242cf3bb246.000003
dmctl で次の
purge-relayコマンドを実行すると、e4e0e8ab-09cc-11e9-9220-82cc35207219.000002/mysql-bin.000001より前のすべてのリレー ログ ファイルがパージされます。これは、deb76a2b-09cc-11e9-9129-5242cf3bb246.000001のすべてのリレー ログ ファイルです。» purge-relay -s mysql-replica-01 --filename mysql-bin.000001 --sub-dir e4e0e8ab-09cc-11e9-9220-82cc35207219.000002dmctl で次の
purge-relayコマンドを実行すると、現在の(deb76a2b-09cc-11e9-9129-5242cf3bb246.000003) ディレクトリのmysql-bin.000001より前のすべてのリレー ログ ファイルが削除されます。これは、deb76a2b-09cc-11e9-9129-5242cf3bb246.000001とe4e0e8ab-09cc-11e9-9220-82cc35207219.000002のすべてのリレー ログ ファイルです。» purge-relay -s mysql-replica-01 --filename mysql-bin.000001