TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

データ移行リレーログ

データ移行（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ファイルのrelay.metaです）、DM-workerはrelay.metaによって記録された位置から移行を再開します。

  • 有効なローカルリレーログが存在しないが、ソース設定ファイルでrelay-binlog-nameまたはrelay-binlog-gtidが指定されている場合：

    • 非GTIDモードでは、 relay-binlog-nameが指定されている場合、DM-workerは指定されたbinlogファイルから移行を開始します。
    • GTIDモードでは、 relay-binlog-gtidが指定されている場合、DM-workerは指定された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": ""
}

ノート：

DMv2.0.2より後のDMv2.0.xおよびv5.3.0では、ソース構成ファイルの構成項目enable-relayは無効になり、リレーログの有効化と無効化に使用できるのはstart-relayとstop-relayのみです。 DMは、 データソース構成のロードのときにenable-relayがtrueに設定されていることを検出すると、次のメッセージを出力します。

Please use `start-relay` to specify which workers should pull relay log of relay-enabled sources.

コマンド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より前のバージョン（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マスターはリレーログを安全にパージしようとします。

手動データパージ

手動データパージとは、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.000002

  • dmctlで次の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

このページは役に立ちましたか？