Introduction et utilisation de MySQL--pt-osc

Le workflow de pt-osc :
1. Vérifiez si la table de modifications a une clé primaire ou un index unique, et s'il existe un déclencheur
2. Cochez Modifier la structure de la table, créez une table temporaire et exécutez l'instruction ALTER TABLE sur la nouvelle table
3. Créez trois déclencheurs sur la table source pour l'INSERT UPDATE. Opération DELETE
4. Copier les données de la table source vers la table temporaire Pendant le processus de copie, l'opération de mise à jour sur la table source sera écrite dans la nouvelle table
<.>5. Combinez la table temporaire et le renommage de la table source (nécessite un verrouillage de modification des métadonnées et un verrouillage de table à court terme)
6. Supprimez la table source et les déclencheurs pour terminer la modification de la structure de la table. .

##==================================== == =================##
Limites de l'outil pt-osc
1. avoir une clé primaire ou un index unique, s'il n'y a pas d'outil, il cessera de fonctionner
2 Si l'opération de filtrage de l'environnement de réplication en ligne est trop compliquée, l'outil ne fonctionnera pas 3. S'il est activé, mais lorsque le maître et l'esclave sont retardés, l'outil suspendra le travail de copie des données
4. Si la vérification de la charge du serveur maître est allumé, mais la charge du serveur maître est élevée, l'outil suspendra l'opération
5 Mais lorsque la table utilise des clés étrangères, si le paramètre --alter-foreign-keys-method ne l'est pas. utilisé, l'outil ne sera pas exécuté
6. Seules les tables du moteur de stockage Innodb sont supportées et il nécessite plus de 1 fois l'espace libre de la table sur le serveur.

##==================================== == =================##

pt-osc copier les données
En cours de copie des données , l'outil Les données seront divisées en fonction de la clé primaire ou de la clé unique, et le nombre de lignes de données copiées à chaque fois sera limité pour garantir que la copie ne consomme pas trop de ressources du serveur. Afin de garantir que les données de la table source et de la table cible sont les mêmes, utilisez VERROUILLAGE EN MODE PARTAGE pour obtenir les dernières données du segment de données à copier et ajoutez un verrou partagé aux données pour empêcher d'autres sessions de les modifier. les données. Utilisez LOW_PRIORITY IGNORE pour insérer les données dans la nouvelle table. Le mot-clé LOW_PRIORIT oblige l'opération d'insertion à attendre que les autres opérations qui accèdent à la table soient terminées avant de l'exécuter. Le mot-clé INGORE entraîne l'ignorance des nouvelles données et leur insertion. il existe une clé primaire en double ou une clé d'index unique dans la table.

Script de copie de données lors de la modification de la table `testdb1`.`tb1001` :

## Obtenez d'abord les données de copie suivantes Limites, indexation forcée peut efficacement éviter les problèmes avec les plans d'exécution

SELECT /*!40001 SQL_NO_CACHE */ `id` FROM `testdb1`.`tb1001` FORCE INDEX(`PRIMARY`) WHERE ((` id` > Copie trop de données bloquent les autres réponses pendant une longue période
INSERT LOW_PRIORITY IGNORE INTO `testdb1`.`_tb1001_new` (`id`, `c1`, `c6`) SELECT `id`, `c1 `, `c6` FROM `testdb1`.`tb1001` FORCE INDEX(`PRIMARY`) OÙ ((`id` >= '8394306')) ET ((`id` <= '8416562')) VERROUILLAGE MODE DE PARTAGE /*pt-online-schema-change 14648 copie nibble*/

##================= ====================================##

pt-osc Déclencheur

L'outil pt-osc crée trois déclencheurs AFTER sur la table source pour l'opération INSERT UPDATE DELETE. Le déclencheur DELETE utilise DELETE IGNORE pour garantir que les données de la table source et de la nouvelle table sont supprimées, tandis que INSERT. et UPDATE Le déclencheur utilise REPLACE INTO pour garantir que les nouvelles données de la table sont cohérentes avec les données de la table source.

Étant donné que MySQL limite qu'il ne peut y avoir qu'un seul déclencheur du même type, il est nécessaire de vérifier s'il y a un déclencheur sur la table source avant de l'exécuter afin de garantir l'efficacité. et la commodité de la suppression et de la mise à jour, les données de la table source sont fragmentées, elles nécessitent donc une clé primaire ou un index unique sur la table.

##==================================== == =================##
L'impact sur les performances de l'hôte de pt-osc

Pour éviter d'affecter excessivement les performances de l'hôte, l'outil pt-osc les limite à travers les aspects suivants :
1. Contrôlez la taille des données de chaque copie via les paramètres chunk-size et chunk-time .
2. Vérifiez la pression actuelle de l'hôte via le paramètre max-load. Une fois chaque copie de morceau terminée, la commande SHOW GLOBAL STATUS LIKE 'Threads_running' sera exécutée pour vérifier le nombre de threads en cours d'exécution. La valeur par défaut Threads_running=25, si la valeur maximale n'est pas spécifiée, 120 % de la valeur actuelle sera prise comme valeur maximale. Si elle dépasse le seuil, la copie des données sera suspendue

##================ ================================ =======##
pt -osc délai de copie de la bibliothèque esclave

Pour les entreprises sensibles au délai de copie, vous pouvez contrôler le délai de copie via les paramètres suivants :

-- max-log
est par défaut de 1 s. Une fois la copie de chaque morceau terminée, les informations de délai de l'esclave. La bibliothèque spécifiée par le paramètre check-slave-lag sera vérifiée si elle dépasse le seuil max-log, alors suspendez la copie des données jusqu'à ce que le délai de copie soit inférieur au seuil max-log. La vérification des informations de latence de réplication repose sur la valeur de la colonne Seconds_Behind_Master renvoyée dans l'instruction SHOW SLAVE STATUS.

--check-interval
Lorsqu'un délai de réplication se produit et que les données sont mises en pause, le délai de réplication est vérifié périodiquement en fonction du temps spécifié par check -intervalle jusqu'au délai Le temps est inférieur au seuil max-log, puis reprendre la copie des données

--check-slave-lag
IP de l'esclave qui doit vérifier le délai de réplication
Si le paramètre check-slave-lag est spécifié et que la bibliothèque esclave ne peut pas se connecter normalement ou si le thread IO de la bibliothèque esclave et le thread SQL sont arrêtés, il sera considéré que il y a un délai entre le maître et l'esclave, provoquant la suspension de l'opération de copie des données.
Si le paramètre check-slave-lag n'est pas spécifié, le délai de la bibliothèque esclave sera toujours vérifié par défaut, mais le délai de réplication n'entraînera pas la suspension de la réplication des données.

##==================================== == =================##
Paramètres du chunk pt-osc
Dans le document d'aide de pt -osc , les paramètres concernant chunk sont les suivants :

--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)

Lorsque ni la taille ni la durée du chunk ne sont spécifiées, chunk- Le la valeur par défaut de la taille est 1000 et la valeur par défaut du temps de bloc est de 0,5 S. Les données sont copiées en fonction de la taille du bloc pour la première fois, puis la taille de la taille du bloc est ajustée dynamiquement en fonction de l'heure. première copie pour s'adapter aux changements de performances du serveur. Par exemple, la dernière fois que la copie de 1 000 lignes a pris 0,1 S, la prochaine fois, la taille du bloc est ajustée dynamiquement à 5 000.
Si la valeur de chumk-size est explicitement spécifiée ou si chunk-time est spécifié comme 0, les données seront copiées en fonction de la taille du morceau à chaque fois.

##=====================================================##
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`.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!