MySQL オンライン DDL ツール gh-ost 原理分析

1. はじめに

gh-ost は golang 言語をベースにした、GitHub のオープンソース DDL ツールです。これは GitHub の Online Schema Transmogrifier/Transfigurator/Transformer/Thingy の略で、GitHub のオンライン テーブル定義コンバーターを意味します。

1.1 原則

主な実装原則は、最初に 2 つのテーブルを作成することです。1 つはシャドウ テーブル _gho で、gh-ost は元のテーブル データと増分データをこのテーブルに適用し、最後にこのテーブルと元のテーブルの間でテーブル名を切り替えます。もう 1 つは、シグナル マーカー、ハートビートなどの変更ログ データを格納する _ghc テーブルです。次に、gh-ost は 2 つの goroutine を開始します。1 つは元のテーブル データをコピーするためのもので、もう 1 つは増分 binlog を _gho テーブルに適用するためのものです。2 つの goroutine は並列で実行されるため、データが最初にコピーされるか、binlog が最初に適用されるかを気にする必要はありません。ここで挿入ステートメントが調整されるため、まずコピーした insert into が insert ignore into に書き換えられ、binlog 内の insert into が replace into に書き換えられ、2 つの goroutine の並列化が適切にサポートされます。しかし、このような調整はすべての DDL に適用できるのでしょうか?答えはノーです。最後に、元のテーブル データがすべてコピーされると、gh-ost はより安全なアトミック スワップを使用してテーブル スワップ フェーズに入ります。

1.2 プロセス

1. 外部キーとトリガーを確認します。
2. テーブルの主キー情報を確認します。
3. マスターデータベースかスレーブデータベースか、log_slave_updatesが有効になっているか、binlog情報を確認する
4. ghoとdelで終わる一時テーブルが存在するかどうかを確認します。
5. データ移行情報やバイナリログ情報などを格納するために、ghc で終わるテーブルを作成します。
---上記の検証段階
6. ストリーム接続を初期化し、バイナリログ監視を追加する
--- 次の移行フェーズ
7. ghoで終わる一時テーブルを作成し、ghoで終わる一時テーブルに対してDDLを実行します。
8. トランザクションを開始し、主キー ID に従って gho で終わるテーブルにソース テーブル データを書き込み、送信して、binlog を適用します。
---次のカットオーバー段階
9. ソース テーブルをロックし、テーブルの名前を変更します。ソース テーブルの名前を source_del テーブルに変更し、gho テーブルの名前をソース テーブルに変更します。
10. ghc テーブルをクリーンアップします。

1.3 特徴

1. トリガーなし: binlog ログを分析して、テーブル内のデータの変更を監視します。

2. 軽量: トリガーを使用しないため、操作中のメイン データベースへの影響は最小限に抑えられ、同時実行性やロックについて心配する必要がありません。

3. 一時停止可能: すべての書き込み操作は gh-ost によって制御されます。レート制限がある場合、gh-ost はマスターへのデータの書き込みを一時停止し、内部追跡テーブルを作成し、最小限のシステム オーバーヘッドでこのテーブルにハートビート イベントを書き込むことができます。

4. 動的制御: gh-ost は、Unix ソケット ファイルまたは TCP ポート (構成可能) を介して要求をリッスンでき、オペレーターはコマンドの実行後に対応するパラメーターを変更できます。

5. 監査可能: プログラム インターフェイスを使用して、gh-ost のステータスを取得し、現在の進行状況、主要なパラメータの構成、現在のサーバー ID などを報告できます。

6. テスト可能: gh-ost にはテストのサポートが組み込まれており、--test-on-replica フラグを使用して指定できます。これにより、レプリカに対してミューテーションが実行され、その終了時に gh-ost はレプリケーションを停止し、テーブルを交換し、交換を元に戻し、両方のテーブルを同期した状態に保ち、レプリケーションを停止します。 2 つのテーブルのデータを自由にテストして比較できます。

1.4 githubアドレス

https://github.com/github/gh-ost/

2. テスト環境:

2.1 テストサーバー

メインデータベース: 110.119.120.231

図書館から：110.119.120.230

2.2 インストール

/usr/local/src/ をコピーします

https://github.com/github/gh-ost/releases/download/v1.0.48/gh-ost-binary-linux20190214020851.tar.gz をダウンロードしてください

tar xzvf gh-ost-binary-linux-20190214020851.tar.gz -C /usr/local/
ln -s /usr/local/gh-ost /usr/bin/gh-ost

2.3 ユーザーを作成する

'ghost' によって識別されるユーザー ghost@'110.%' を作成します。

*.* のすべての権限を ghost@'110.%' に付与します。

権限をフラッシュします。

2.4 コマンドパラメータ

gh-ost の使用法:
 --aliyun-rds: Alibaba Cloud Database で実行するかどうか。真実
 --allow-master-master: gh-ost をデュアルマスター レプリケーション アーキテクチャで実行できるようにするかどうか。通常は、-assume-master-host パラメータと一緒に使用します。--allow-nullable-unique-key: gh-ost がデータ移行が依存する一意のキーを NULL にすることを許可します。デフォルトでは、NULL 一意のキーは許可されません。データ移行の対象となる一意のキーが NULL 値を許可する場合、不正確なデータが生成される可能性があります。注意して使用してください。
 --allow-on-master: gh-ost がマスター上で直接実行できるようにします。 gh-ost が接続するデフォルトのスレーブ。さらに、単一インスタンス上の DDL の場合、単一インスタンスはマスター データベースと同等であり、--allow-on-master パラメータと ROW モードを有効にする必要があります。
 --alter 文字列:DDL ステートメント --approve-renamed-columns ALTER: 列の名前を変更すると、gh-ost はこれを認識し、列名の変更理由を尋ねます。デフォルトでは、--approve-renamed-columns ALTER を指定しない限り、gh-ost は続行しません。
 --ask-pass:MySQL パスワード --assume-master-host 文字列:「ip:port」または「hostname:port」の形式で、gh-ost のマスター データベースを指定します。これは、マスター-マスター アーキテクチャの場合、または gh-ost がマスターを見つけられない場合に役立ちます。
 --assume-rbr: gh-ost が接続されているデータベース インスタンスに binlog_format=ROW が設定されている場合は、-assume-rbr を指定できます。これにより、スレーブ上で stop slave と start slave が実行されなくなり、gh-ost ユーザーは実行に SUPER 権限を必要としなくなります。
 --チェックフラグ
 --chunk-size int: 各反復で処理する行数 (許容範囲: 100-100000)、デフォルト値は 1000 です。
 --concurrent-rowcount: このパラメータが True (デフォルト) の場合、行のコピー後、gh-ost は (explain select count(*) を使用して) 行数を推定し、ETA を調整します。それ以外の場合、gh-ost は最初に行数を推定してから行のコピーを開始します。
 --conf 文字列: gh-ost 構成ファイルのパス。
 --critical-load string: カンマで区切られた status-name=values のリスト。MySQL ステータスが対応する値を超えると、gh-ost は終了します。 -critical-load Threads_connected=20,Connections=1500 は、MySQL のステータス値が Threads_connected>20,Connections>1500 の場合、データベースの重大な負荷により gh-ost が停止して終了することを意味します。
 カンマ区切りの status-name=threshold、--max-load と同じ形式。ステータスがしきい値を超えると、アプリはパニックを起こして終了します。
 --critical-load-hibernate-seconds int : 臨界負荷に達すると、gh-ost は指定された時間休止状態になります。 どのサーバーからも何も読み書きしません。
 --critical-load-interval-millis int: 値が 0 の場合、gh-ost は臨界負荷に達するとすぐに終了します。値が 0 でない場合、gh-ost は -critical-load に達したときに -critical-load-interval-millis 秒後に再度チェックします。2 回目のチェック後も -critical-load に達した場合、gh-ost は終了します。
 --cut-over 文字列: カットオーバー タイプ (アトミック/ツーステップ) を選択します。アトミック (デフォルト) タイプのカットオーバーでは github アルゴリズムが使用され、ツーステップ タイプでは facebook-OSC アルゴリズムが使用されます。
 --カットオーバー指数バックオフ
 --cut-over-lock-timeout-seconds int: gh-ost のカットオーバー フェーズ中の最大ロック待機時間。ロックがタイムアウトすると、gh-ost はカットオーバーを再試行します。 (デフォルト: 3)
 --database 文字列: データベース名。
 --debug: デバッグモード。
 --default-retries int: パニックが発生する前にさまざまな操作を再試行する回数。 (デフォルトは60)
 --discard-foreign-keys: このパラメータは、外部キーを持つテーブル用です。gh-ost がゴースト テーブルを作成する場合、ゴースト テーブルの外部キーは作成されません。このパラメータは外部キーを削除する場合に便利ですが、それ以外の場合は注意して使用してください。
 --dml-batch-size int: 単一トランザクションで DML イベントを適用するためのバッチ サイズ (範囲 1 ～ 100) (デフォルト 10)
 --exact-rowcount: テーブルの行数を正確にカウントし (select count(*) を使用)、より正確な時間を推定します。
 --execute: 実際にテーブルの変更と移行を実行します。デフォルトは noop で、実行しないことを意味します。テストして終了するだけです。ALTER TABLE ステートメントを実際にデータベースに実装したい場合は、-execute を明示的に指定する必要があります。
 --指数バックオフ最大間隔 int
 --force-named-cut-over: true の場合、'unpostpone | cut-over' 対話型コマンドは移行されたテーブルに名前を付ける必要があります --force-table-names 文字列: 一時テーブルで使用するテーブル名のプレフィックス --heartbeat-interval-millis int: gh-ost ハートビートの頻度の値、デフォルトは 500
  - ヘルプ
 --hooks-hint 文字列: GH_OST_HOOKS_HINT を介してフックに挿入される任意のメッセージ --hooks-path 文字列: フック ファイルが保存されるディレクトリ (デフォルトは空、つまりフックは無効)。フックは、このディレクトリ内で同じ命名規則を持つフック ファイルを検索して実行します。
 --host 文字列:MySQL IP/ホスト名
 --initially-drop-ghost-table: gh-ost 操作の前に既存のゴースト テーブルをチェックして削除します。このパラメータは推奨されません。既存のゴースト テーブルを手動で処理してください。デフォルトでは、このパラメータは有効になっていないため、gh-ost は操作を終了します。
 --initially-drop-old-table: gh-ost 操作の前に、既存の古いテーブルをチェックして削除します。このパラメータは推奨されません。既存のゴースト テーブルを手動で処理してください。デフォルトでは、このパラメータは有効になっていないため、gh-ost は操作を終了します。
 --initially-drop-socket-file:gh-ost は既存のソケット ファイルを強制的に削除します。このパラメータは推奨されません。実行中の gh-ost プログラムが削除され、DDL 障害が発生する可能性があります。
 --master-password string:MySQL マスター パスワード --master-user string:MySQL マスター アカウント --max-lag-millis int:マスター スレーブ レプリケーションの最大遅延時間。マスター スレーブ レプリケーションの遅延時間がこの値を超えると、gh-ost はスロットル対策を講じます。デフォルト値: 1500 秒。
 --max-load 文字列: カンマ区切りのステータス名 = しきい値、例: 'Threads_running=100,Threads_connected=500'。ステータスがしきい値を超えると、アプリは書き込みを制限します。
 --migrate-on-replica: gh-ost はマスターではなくレプリカ上で移行を実行します。 
 --nice-ratio float: 各チャンク期間のスリープ時間（範囲は [0.0…100.0]）。 0: 各チャンク期間でスリープなし。つまり、1 つのチャンクが次々に実行されます。1: 行コピーごとにさらに 1 ミリ秒スリープします。0.7: 行コピーごとに 10 ミリ秒スリープします。
 --ok-to-drop-table: gh-ost 操作が完了すると、古いテーブルが削除されます。デフォルトでは、古いテーブルは削除されず、_tablename_del テーブルが存在します。
 --panic-flag-file 文字列: このファイルが作成されると、gh-ost は直ちに終了します。
 --password string : MySQL パスワード --port int : MySQL ポート (スレーブが望ましい) --postpone-cut-over-flag-file string : このファイルが存在する場合、gh-ost のカットオーバー フェーズは延期され、ファイルが削除されるまでデータは引き続き複製されます。
 --quiet: 静音モード。
 --replica-server-id uint : gh-ost の server_id
 --replication-lag-query 文字列: 非推奨 --serve-socket-file 文字列: gh-ost のソケット ファイルへの絶対パス。
 --serve-tcp-port int: gh-ost に使用するポート。デフォルトは閉じたポートです。
 --skip-foreign-key-checks: テーブルに外部キーがないことを確認して、gh-ost 検証をスキップする場合は、「true」に設定します。
 --skip-renamed-columns ALTER: 列の名前を変更すると (例: 列の変更)、gh-ost はこれを認識し、列名の変更理由を尋ねます。デフォルトでは、gh-ost はコマンドを続行しません。このパラメータは、gh-ost に列の移行をスキップし、名前が変更された列を don’t care 列として扱うように指示します。この操作は危険です。列内のすべての値が失われます。
 --stack: エラー スタック トレースを追加します。
 --switch-to-rbr: gh-ost に、スレーブ リポジトリの binlog_format を ROW 形式に自動的に切り替えるように指示します。
 --table 文字列: テーブル名 --test-on-replica: スレーブでのデータ移行を含め、スレーブで gh-ost をテストします。データ移行が完了したら、スレーブを停止し、すぐに元のテーブルをゴースト テーブルと交換し、すぐに元に戻します。 2 つのテーブルを比較できるように、スレーブを停止し続けます。
 --test-on-replica-skip-replica-stop: -test-on-replica を実行する場合、このパラメータはプロセス中にスレーブを停止する必要がないことを意味します。
 --throttle-additional-flag-file 文字列: このファイルが作成されると、gh-ost 操作は直ちに停止します。このパラメータは、複数の gh-ost 操作が同時に実行されている場合に、ファイルを作成してすべての gh-ost 操作を停止したり、ファイルを削除してすべての gh-ost 操作を再開したりするために使用できます。
 --throttle-control-replicas 文字列: マスター-スレーブ レプリケーションの遅延を確認する必要があるすべてのスレーブ ライブラリを一覧表示します。
 --throttle-flag-file 文字列: このファイルが作成されると、gh-ost 操作は直ちに停止します。このパラメータは、単一の gh-ost 操作を制御するのに適しています。 -throttle-additional-flag-file 文字列は、複数の gh-ost 操作を制御するのに適しています。
 --throttle-http 文字列
 --throttle-query 文字列: スロットルクエリ。 1 秒ごとに 1 回実行されます。戻り値が 0 の場合、スロットルは必要ありません。戻り値 > 0 の場合、スロットルを実行する必要があります。このクエリは移行されたサーバー上で実行されるため、軽量であることを確認してください。
 --timestamp-old-table: 古いテーブル名にタイムスタンプを使用します。 これにより、古いテーブル名の相互移行が一意になり、競合がなくなります --tungsten: gh-ost に、tungsten レプリケーション トポロジを実行していることを伝えます。
 --user 文字列 :MYSQL ユーザー --verbose
 --バージョン

3. 動作モード

モード1: スレーブデータベースに接続し、マスターデータベースで変更する

これは、gh-ost がスレーブを検索し、クラスターのマスターを見つけてそれに接続するデフォルトのモードです。変更操作の具体的な手順は次のとおりです。

1. マスター データベースの行データを読み書きします。

2. スレーブ データベースでバイナリ ログ イベントを読み取り、変更をマスター データベースに適用します。

3. スレーブ データベースのテーブル形式、フィールド、主キー、行の合計数などを確認します。

4. スレーブ上で gh-ost 内部イベント ログ (ハートビートなど) を読み取ります。

5. メインデータベースでテーブル切り替えを完了します。

メイン データベース ログ形式が SBR の場合、ツールも正常に動作します。ただし、スレーブはバイナリ ログが有効 (log_bin、log_slave_updates) かつ binlog_format=ROW (gh-ost はスレーブから読み取るバイナリ ファイル) に設定されている必要があります。

使用例:

# gh-ost --initially-drop-old-table --initially-drop-ghost-table --user="ghost" --password="ghost" --host=110.119.120.230 --port=3306 --database="test" --table="t1" --verbose --alter="ADD COLUMN y1 varchar(10),add column y2 int not null default 0 comment 'test' " --assume-rbr --execute

パラメータの意味:

--initially-drop-old-table: gh-ost 操作の前に既存の古いテーブルをチェックして削除します。

--initially-drop-ghost-table: gh-ost 操作の前に既存のゴースト テーブルをチェックして削除します。

--verbose: 実行プロセスのログを出力します

--assume-rbr: gh-ost が接続されているデータベース インスタンスに binlog_format=ROW が設定されている場合は、-assume-rbr を指定できます。これにより、スレーブ上で stop slave と start slave を実行する必要がなくなります。gh-ost を実行するユーザーには SUPER 権限は必要ありません。

モード2: メインデータベースを直接変更する

スレーブ ライブラリがない場合、またはスレーブ ライブラリを操作したくない場合は、マスター ライブラリを直接使用できます。 gh-ost はすべての操作をマスター上で直接実行します。上記のマスター/スレーブ レプリケーションの遅延を引き続き確認できます。

1) マスターデータベースは行形式でバイナリログを生成する必要があります

2) このモードを有効にするには、gh-ost を起動するときに --allow-on-master オプションを使用する必要があります。

# gh-ost --initially-drop-old-table --initially-drop-ghost-table --user="ghost" --password="ghost" --host="110.119.120.231" --port=3306 --database="test" --table="t2" --verbose --alter="列 test_field varchar(256) デフォルト '';" を追加 --exact-rowcount --serve-socket-file=/tmp/gh-ost.t2.sock --panic-flag-file=/tmp/ghost.panic.t2.flag --postpone-cut-over-flag-file=/tmp/ghost.postpone.t2.flag --allow-on-master --execute

パラメータの意味:

--exact-rowcount: テーブルの行数を正確にカウントし (select count(*) を使用)、より正確な時間を推定します。

--serve-socket-file: gh-ost ソケット ファイルへの絶対パス。たとえば、--serve-socket-file=/tmp/gh-ost.t1.sock は、リスニング用のソケット ファイルを作成し、インターフェイスを介してパラメータを調整します。操作中に負荷と待ち時間が増加すると、操作を終了し、チャンク サイズなどのパラメータを再設定する必要があります。その後、操作コマンドを再実行できます。動的な調整は、ソケット インターフェイスを介して行うことができます。

＃一時停止

エコースロットル | socat - /tmp/gh-ost.t1.sock

＃回復する

エコーなしスロットル | socat - /tmp/gh-ost.t1.sock

速度制限パラメータを変更します。

echo チャンクサイズ=1500 | socat - /tmp/gh-ost.t1.sock
エコー最大ラグミリ=2000 | socat - /tmp/gh-ost.t1.sock

echo 最大負荷=Thread_running=30 | socat - /tmp/gh-ost.t1.sock

--panic-flag-file: このファイルは、実行中の gh-ost を直ちに終了するために作成されます。一時ファイルのクリーンアップは手動で行う必要があります。

--postpone-cut-over-flag-file: このファイルが存在する場合、gh-ost のカットオーバー フェーズは延期されます。データは引き続きコピーされますが、このファイルが削除されるまでテーブルは切り替えられません。

--allow-on-master: gh-ost がマスター上で直接実行できるようにします。

モード3: スレーブ上で変更とテストを行う

このモードでは、スレーブ データベースに変更が加えられます。すべての操作はスレーブ データベースで実行され、マスター データベースには影響しません。操作中、レプリカ データを最新の状態に保つために、gh-ost は時々一時停止します。

--test-on-replica は、操作がテスト目的のみであることを示します。最終的なスイッチオーバー操作の前にレプリケーションが停止されます。元のテーブルと一時テーブルが交互に切り替わり、最終的に元のテーブルは変更されません。マスターとスレーブ間のレプリケーションが一時停止されているときは、2 つのテーブルのデータを確認して比較できます (スレーブを停止したくない場合は、パラメータ --test-on-replica-skip-replica-stop を追加できます)。

# gh-ost --initially-drop-old-table --initially-drop-ghost-table --user="ghost" --password="ghost" --host=110.119.120.230 --port=3306 --database="test" --table="t3" --verbose --alter="ADD COLUMN abc1 varchar(10),add column abc2 int not null default 0 comment 'test' " --test-on-replica --assume-rbr --execute

RDS の制限:

1. ユーザーにスーパー権限がないため、使用中に --assume-rbr コマンドを追加する必要があります。gh-ost は、binlog 自体が行モードであると想定し、それを変更しません。 Alibaba Cloud RDS 上の binlog もデフォルトで行モードになっているので問題ありません。

2. その他の権限、主に REPLICATION SLAVE、REPLICATION CLIENT は、binlog をプルして取得することもできます。

3. スタンバイ データベースに接続してバイナリ ログを取得できません。スタンバイ データベースは通常、ユーザーに対して透過的であるため、gh-ost はプライマリ データベースに直接接続する必要があり、プライマリ データベースの負荷が増加する可能性があります。使用する場合、--allow-on-master と --assume-master-host を追加する必要があります。 公式に推奨されている方法は、バックアップ データベースの 1 つに接続することです。これは、負荷の高い SELECT 操作がいくつかあるため、それらをバックアップ データベースに配置するのが最善だからです。

4. Alibaba Cloud Database で実行するには、パラメータ --aliyun-rds を追加する必要があります。 現在使用している場合は、次のパラメータを追加することを忘れないでください: --allow-on-master --assume-rbr --assume-master-host --aliyun-rds

4. gh-ostとpt-oscの比較

4.1 pt-oscの簡単な紹介

pt-osc ワークフロー
1. 変更テーブルに主キーまたは一意のインデックスがあるかどうか、トリガーがあるかどうかを確認します。
2. テーブル構造を確認して変更し、一時テーブルを作成し、新しいテーブルに対してALTER TABLEステートメントを実行します。
3. ソース テーブルに、それぞれ INSERT、UPDATE、DELETE 操作用の 3 つのトリガーを作成します。
4. ソース テーブルから一時テーブルにデータをコピーします。コピー処理中に、ソース テーブルの更新内容が新しく作成されたテーブルに書き込まれます。
5. 一時テーブルとソーステーブルの名前を変更します（メタデータ変更ロックが必要であり、テーブルを短時間ロックする必要があります）
6. ソース テーブルとトリガーを削除して、テーブル構造の変更を完了します。

pt-osc ツールの制限
1. ソース テーブルには主キーまたは一意のインデックスが必要です。そうでない場合、ツールは動作を停止します。
2. オンラインレプリケーション環境のフィルタ操作が複雑すぎると、ツールは機能しません。
3. レプリケーション遅延チェックがオンになっているが、マスタースレーブ遅延が発生した場合、ツールはデータコピー作業を中断します。
4. メインサーバーの負荷チェックがオンになっているが、メインサーバーの負荷が高い場合、ツールは動作を中断します。
5. テーブルが外部キーを使用する場合、--alter-foreign-keys-method パラメータを使用しないとツールは実行されません。
6. Innodb ストレージ エンジン テーブルのみがサポートされており、サーバー上にテーブルの 1 倍以上の空き領域が必要です。

では、pt-osc と比較した gh-ost の具体的な利点は何でしょうか?以下では、その最も重要な 2 つの機能について簡単に紹介します。

4.2 トリガーレス

gh-ost が登場する前は、Percona の pt-osc、Facebook の OSC など、サードパーティの MySQL DDL ツールはすべてトリガーを使用して実装されていました。 gh-ost が使用するメカニズムはそれらとはまったく異なり、MySQL binlog を介してデータを同期します。gh-ost 自体は偽のスレーブとして登録されており、クラスター内のマスターまたはスレーブから binlog をプルし、それをリアルタイムで解析し、変更テーブルのすべての DML 操作をシャドウ テーブルに再適用できます。したがって、リリース中に変更テーブルで発生する DML 操作では、トリガーとロックの競合によって発生するパフォーマンスのオーバーヘッドを完全に回避できます。

さらに、通常はクラスタ内のスレーブノードをターゲットパブリッシングマシンとして選択しますが、スレーブは通常、ビジネスを実行しません。このように、binlog 解析のオーバーヘッドはビジネスを提供するマスターに負担がかからず、非同期 DML ステートメントの再生のみになります。

4.3 動的に制御可能

もう 1 つの最も重要な機能は動的制御です。これは、これまで他のサードパーティのオープン ソース ツールでは利用できませんでした。

以前 pt-osc 経由で公開した場合、コマンドの実行後に停止して再起動しない限り、パラメータを変更することはできません。リリースが 90% 完了し、さまざまな理由により突然サーバーの負荷が増加したとします。業務に影響を与えないようにするには、リリースを停止し、パフォーマンスが回復するのを待ってから再開するしかありません。

pt-osc を通じて公開されるテーブルはすべて大きなテーブルであり、時間がかかるため、このようなシナリオに遭遇すると非常に困惑します。したがって、リリース内のパラメータを動的に調整できるかどうかは非常に重要です。 gh-ost はソケット サーバーも実装しています。ソケットを介して公開プロセスとリアルタイムでやり取りできます。リアルタイムの一時停止、再開、および外部の変更に適応するための多くのパラメータの動的な調整をサポートできます。

5. 参考文献

1. gh-ost 原則

https://www.cnblogs.com/mysql-dba/p/9901589.html

2. 技術共有 | gh-ost オンライン DDL 変更ツール

https://zhuanlan.zhihu.com/p/83770402

3. 実践スキル | Ctripのデータベース公開システムの進化

https://blog.csdn.net/ctrip_tech/article/details/108395676

4.MySQLオンラインDDL gh-ost使用手順

https://www.cnblogs.com/zhoujinyi/p/9187421.html

5.MySQL--pt-oscツールの学習

https://www.cnblogs.com/TeyGao/p/7160421.html

MySQLオンラインDDLツールgh-ostに関するこの記事はこれで終わりです。MySQLオンラインDDL gh-ostの詳細については、123WORDPRESS.COMの以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも123WORDPRESS.COMをよろしくお願いいたします。