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 データのコピー
データのコピーのプロセス中に、ツールは主キーまたは一意のキーに従ってデータを分割し、毎回コピーされるデータの行数 これにより、コピーによってサーバー リソースが過度に消費されなくなります。ソーステーブルとターゲットテーブルのデータが同じであることを確認するには、LOCK IN SHARE MODE を使用してコピーするデータセグメントの最新データを取得し、そのデータに共有ロックを追加して、他のセッションが変更できないようにします。データを新しいテーブルに挿入するには、LOW_PRIORITY IGNORE を使用します。キーワード LOW_PRIORIT を使用すると、挿入操作はテーブルにアクセスする他の操作が完了するまで待機し、キーワード INGORE を使用すると、新しいデータは無視され、挿入されません。テーブル内に重複した主キーまたは一意のインデックス キーがあります。
テーブル `testdb1`.`tb1001` を変更するときのデータ コピー スクリプト:
## 最初に次のコピー データの境界を取得し、強制インデックス作成により実行計画の問題を効果的に回避できます
SELECT / *!40001 SQL_NO_CACHE */ `id` FROM `testdb1`.`tb1001` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= '8394306')) ORDER BY `id` LIMIT 22256, 2 /*nextチャンク境界*/
## コピーデータの境界制限を通じて、一度に大量のデータがコピーされ、他の応答が長時間ブロックされることを防ぎます
INSERT LOW_PRIORITY IGNORE INTO `testdb1`.`_tb1001_new` (` id`, ` c1`, `c6`) SELECT `id`, `c1`, `c6` FROM `testdb1`.`tb1001` FORCE INDEX(`PRIMARY`) WHERE ((`id` >= '8394306' )) AND ( (`id`
pt-osc トリガーデバイス
pt-osc ツールは、INSERT UPDATE DELETE 操作のソース テーブルに 3 つの AFTER トリガーを作成します。DELETE トリガーは DELETE IGNORE を使用して、ソース テーブルと新しいテーブルのデータが確実に削除されるようにします。一方、INSERT トリガーと UPDATE トリガーは、 REPLACE.INTO を使用して、新しいテーブル データがソース テーブル データと一致していることを確認します。
MySQL は同じ種類のトリガーを 1 つだけに制限しているため、ソーステーブルのデータの削除と更新の効率と利便性を確保するために、実行前にソーステーブルにトリガーがあるかどうかを確認する必要があります。テーブルに主キーまたは一意のインデックスが必要です。
##=========================================== ==== =========##
ホストのパフォーマンスに対する pt-osc の影響
ホストのパフォーマンスへの過度の影響を避けるために、pt-osc ツールは次の環境で制限されています。以下の側面:
1. パラメータ chunk-size と chunk-time は、データの各コピーのサイズを制御します
2. 各チャンクのコピー後に、パラメータ max-load を使用します。完了すると、SHOW GLOBAL STATUS LIKE 'Threads_running' コマンドが実行され、現在実行中のスレッドの数が確認されます。デフォルトでは Threads_running=25 で、最大値が指定されていない場合は、現在の値の 120% が取得されます。最大値として、しきい値を超えるとデータコピーが一時停止されます
##======= ==================== ==========================##
pt-osc のライブラリからのコピー遅延
コピーに敏感な企業向け遅延では、次のパラメータを使用してコピー遅延を制御できます:
--max-log
デフォルトは 1 秒で、各チャンクがコピーされます。完了後、チェックで指定されたスレーブ データベースの遅延情報がコピーされます。スレーブラグパラメータがチェックされ、最大ログしきい値を超えた場合、レプリケーション遅延が最大ログしきい値を下回るまでデータレプリケーションが一時停止されます。レプリケーション遅延情報の確認は、SHOW SLAVE STATUS ステートメントで返される Seconds_Behind_Master 列の値に依存します。
--check-interval
レプリケーション遅延が発生し、データレプリケーションが一時停止されると、遅延時間が max-log を下回るまで、check-interval で指定された時間に従ってレプリケーション遅延が定期的にチェックされます。しきい値を超えると、データ コピーが再開されます
--check-slave-lag
レプリケーション遅延のスレーブ IP をチェックする必要があります
check-slave-lag パラメータとスレーブが正常に接続できないか、スレーブ IO スレッドと SQL スレッドが停止すると、マスターとスレーブの間に遅延が発生し、データ コピー操作が中断されると考えられます。
check-slave-lag パラメーターが指定されていない場合でも、スレーブ ライブラリの遅延はデフォルトでチェックされますが、レプリケーションの遅延によってデータ レプリケーションが一時停止されることはありません。
##=========================================== ==== =========##
pt-oscのチャンク設定
pt-oscのヘルプドキュメントでは、チャンクに関するパラメータは以下の通りです:
--chunk-index=s Prefer this index for chunking tables --chunk-index-columns=i Use only this many left-most columns of a --chunk-index --chunk-size=z Number of rows to select for each chunk copied (default 1000) --chunk-size-limit=f Do not copy chunks this much larger than the desired chunk size (default 4.0) --chunk-time=f Adjust the chunk size dynamically so each data-copy query takes this long to execute (default 0.5)
チャンクの場合 - サイズもチャンク時間も指定されていない場合、チャンクサイズのデフォルト値は 1000、チャンク時間のデフォルト値は 0.5S です。データは初めてチャンクサイズに従ってコピーされます。次に、最初のコピーの時間に基づいて chumk-size のサイズを動的に調整し、サーバーのパフォーマンスの変化に適応させます。たとえば、前回 1000 行のコピーに 0.1 秒かかりましたが、次回は chumk-size が 0.1 秒かかりました。動的に 5000 に調整されます。
chumk-sizeの値を明示的に指定するか、chunk-timeに0を指定すると、毎回chunk-sizeに従ってデータがコピーされます。
##=====================================================##
pt-osc之alter语句限制
1、不需要包含alter table关键字,可以包含多个修改操作,使用逗号分开,如"drop clolumn c1, add column c2 int"
2、不支持rename语句来对表进行重命名操作
3、不支持对索引进行重命名操作
4、如果删除外键,需要对外键名加下划线,如删除外键fk_uid, 修改语句为"DROP FOREIGN KEY _fk_uid"
##=====================================================##
pt-osc之命令模板
## --execute表示执行
## --dry-run表示只进行模拟测试
## 表名只能使用参数t来设置,没有长参数
pt-online-schema-change \--host="127.0.0.1" \--port=3358 \--user="root" \--password="root@root" \--charset="utf8" \--max-lag=10 \--check-salve-lag='xxx.xxx.xxx.xxx' \--recursion-method="hosts" \--check-interval=2 \--database="testdb1" \t="tb001" \--alter="add column c4 int" \--execute
pt-osc之命令输出
上面命令执行输出如下:
No slaves found. See --recursion-method if host 171DB166 has slaves. Will check slave lag on: 170DB166 Operation, tries, wait: copy_rows, 10, 0.25 create_triggers, 10, 1 drop_triggers, 10, 1 swap_tables, 10, 1 update_foreign_keys, 10, 1 Altering `testdb1`.`tb001`... Creating new table... Created new table testdb1._tb001_new OK. Altering new table... Altered `testdb1`.`_tb001_new` OK. 2016-04-28T23:18:04 Creating triggers... 2016-04-28T23:18:04 Created triggers OK. 2016-04-28T23:18:04 Copying approximately 1 rows... 2016-04-28T23:18:04 Copied rows OK. 2016-04-28T23:18:04 Swapping tables... 2016-04-28T23:18:04 Swapped original and new tables OK. 2016-04-28T23:18:04 Dropping old table... 2016-04-28T23:18:04 Dropped old table `testdb1`.`_tb001_old` OK. 2016-04-28T23:18:04 Dropping triggers... 2016-04-28T23:18:04 Dropped triggers OK. Successfully altered `testdb1`.`tb001`.
以上がMySQL の紹介と使用法 --pt-oscの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。