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

データ移行リレーログ

データ移行 (DM) リレー ログは、データベースの変更を説明するイベントを含む番号付きファイルのいくつかのセットと、使用されるすべてのリレー ログ ファイルの名前を含むインデックス ファイルで構成されます。

リレー ログが有効になると、DM ワーカーはアップストリームのbinlogをローカル構成ディレクトリに自動的に移行します ( TiUPを使用して DM が展開されている場合、デフォルトの移行ディレクトリは<deploy_dir>/<relay_log>です)。デフォルト値<relay_log>はrelay-dirですが、 アップストリーム データベースコンフィグレーションファイルで変更できます。 v5.4.0 以降、ローカル構成ディレクトリをrelay-dirからDM ワーカー設定ファイルまで構成できます。これは、アップストリーム データベースの構成ファイルよりも優先されます。

ユーザーシナリオ

MySQL では、storage容量が限られているため、最大保持時間に達すると、binlogは自動的に消去されます。アップストリーム データベースがbinlogをパージした後、DM はパージされたbinlog のプルに失敗し、移行タスクは失敗します。移行タスクごとに、DM はbinlogをプルするための接続をアップストリームに作成します。接続が多すぎると、アップストリーム データベースに大きな負荷がかかる可能性があります。

リレー ログが有効になっている場合、同じアップストリーム データベースを持つ複数の移行タスクで、ローカル ディスクにプルされたリレー ログを再利用できます。これにより、上流データベースへの負担が軽減されます。

完全データ移行タスクと増分データ移行タスク ( task-mode=all ) の場合、DM は最初に完全データを移行し、次にbinlogに基づいて増分移行を実行する必要があります。完全な移行フェーズに時間がかかると、上流のbinlogがパージされ、増分移行が失敗する可能性があります。この状況を回避するには、リレー ログ機能を有効にして、DM がローカル ディスクに十分なログを自動的に保持し、増分移行タスクが正常に実行できるようにします。

通常はリレー ログを有効にすることが推奨されますが、次の潜在的な問題に注意してください。

リレー ログはディスクに書き込む必要があるため、外部 IO および CPU リソースを消費します。これにより、データ複製プロセス全体が延長され、データ複製のレイテンシーが増加します。遅延の影響を受けるシナリオでは、リレー ログを有効にすることはお勧めできません。

注記：

DM v2.0.7 以降のバージョンでは、リレー ログの書き込みが最適化されています。レイテンシーと CPU リソースの消費量は比較的低いです。

リレーログを使用する

このセクションでは、リレー ログの有効化と無効化、リレー ログのステータスのクエリ、およびリレー ログのパージの方法について説明します。

リレーログの有効化と無効化

  • 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の場合、このデータ ソースに対してリレー ログ機能が有効になります。

詳しい設定方法についてはアップストリーム データベースコンフィグレーションファイルを参照してください。

さらに、 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のみです。 DM は、 データソース構成のロードのときにenable-relay trueに設定されていることを検出すると、次のメッセージを出力します。

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

コマンドstart-relayでは、指定されたデータ ソースのリレー ログを移行するように 1 つ以上の DM ワーカーを構成できますが、パラメータで指定された DM ワーカーはフリーであるか、アップストリーム データ ソースにバインドされている必要があります。例は次のとおりです。

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の設定方法はアップストリーム データベースコンフィグレーションファイルを参照してください。

リレーログステータスのクエリ

コマンド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 では、手動パージと自動パージという 2 つの方法でリレー ログをパージできます。これら 2 つの方法はいずれも、アクティブなリレー ログをパージしません。

注記：

  • アクティブなリレー ログ: リレー ログはデータ移行タスクによって使用されています。現在、アクティブなリレー ログは Syncer Unit にのみ更新および書き込まれます。すべてモードのデータ移行タスクが完全なエクスポート/インポートに、データ ソースのパージで構成された有効期限よりも長い時間を費やした場合でも、リレー ログはパージされます。

  • 期限切れのリレー ログ: リレー ログ ファイルの最終変更時刻と現在時刻の差が、設定ファイルのexpiresフィールドの値を超えています。

自動パージ

自動パージを有効にし、ソース構成ファイルでその戦略を構成できます。次の例を参照してください。

# 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」で、使用可能なディスク容量が 15 GB 未満の場合、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のすべてのリレー ログ ファイル) がパージされます。 e4e0e8ab-09cc-11e9-9220-82cc35207219.000002とdeb76a2b-09cc-11e9-9129-5242cf3bb246.000003のファイルは保持されます。

    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のすべてのリレー ログ ファイル) がパージされます。 deb76a2b-09cc-11e9-9129-5242cf3bb246.000003のファイルは保持されます。

    purge-relay -s mysql-replica-01 --filename mysql-bin.000001

リレーログの内部仕組み

ここではリレーログの内部仕組みを紹介します。

ディレクトリ構造

リレー ログのローカルstorageのディレクトリ構造の例:

<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 ワーカーは増分シリアル番号を持つ新しい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.

    複数の GTID が存在する場合もあります。

    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がbinlogを受信する位置

  • DM は、保存されたチェックポイント (デフォルトではダウンストリームdm_metaスキーマ内) から各移行タスクが必要とする最も早い位置を取得します。この位置が次のいずれかの位置より後の場合、DM はこの位置から移動を開始します。

  • ローカルリレーログが有効な場合、つまりリレーログに有効なserver-uuid.index 、 subdir 、およびrelay.metaファイルが含まれている場合、DM ワーカーは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 ワーカーは、各サブタスクが移行している最も古いbinlogから、最新のbinlogが移行されるまで移行を開始します。

    • GTID モードでは、DM ワーカーは、最新の GTID が移行されるまで、各サブタスクが移行する最も古い GTID から移行を開始します。

    注記：

    上流のリレー ログがパージされると、エラーが発生します。この場合、移行の開始位置を指定するにはrelay-binlog-gtidを設定する必要があります。

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