Exemple de code sur pt-heartbeat (boîte à outils percona)-tutoriel mysql-php.cn

pt-heartbeat est un outil percona utilisé pour surveiller la latence maître-esclave. La plupart de notre architecture MySQL est toujours basée sur la réplication maître-esclave, comme MHA, MMM, keepalived et d'autres solutions. Dans l'environnement maître-esclave, nous sommes très préoccupés par le problème de retard maître-esclave. Généralement, nous exécutons les instructions suivantes dans la bibliothèque esclave :

mysql> show slave status\G*************************** 1. row ***************************Slave_IO_State: Waiting for master to send event
Master_Host: 172.16.16.35Master_User: root
Master_Port: 3306Connect_Retry: 60Master_Log_File: mysql-bin.000016Read_Master_Log_Pos: 299786938Relay_Log_File: mxqmongodb2-relay-bin.000032Relay_Log_Pos: 299787151Relay_Master_Log_File: mysql-bin.000016Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0Last_Error:
Skip_Counter: 0Exec_Master_Log_Pos: 299786938Relay_Log_Space: 299787451Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0Last_IO_Error:
Last_SQL_Errno: 0Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 353306Master_UUID: 806ede0c-357e-11e7-9719-00505693235d
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 806ede0c-357e-11e7-9719-00505693235d:666-330347Executed_Gtid_Set: 6a4ab82c-4029-11e7-86b0-00505693235d:1-3,
806ede0c-357e-11e7-9719-00505693235d:1-330347Auto_Position: 1Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:1 row in set (0.00 sec)

Copier après la connexion

<.>

Vous pouvez voir clairement l'état du maître et de l'esclave. Généralement, nous surveillerons l'état des deux processus suivants pour déterminer s'il y a une erreur dans le délai maître-esclave :

Slave_IO_Running : Oui

Slave_SQL_Running : Oui

Pour le délai maître-esclave, ce que nous pouvons surveiller le plus est via SMB (Seconds_Behind_Master), mais ce n'est pas très fiable. Ou nous pouvons surveiller la différence entre Read_Master_Log_Pos-Exec_Master_Log_Pos pour voir s'il y a un retard dans la bibliothèque esclave et s'il y a un certain retard avec la bibliothèque maître. Mais celui-ci n’est pas non plus tout à fait parfait. Tout d'abord, regardons SMB. Comment ce paramètre est-il comparé ? SMB est obtenu en comparant l'horodatage actuel du serveur avec l'horodatage de l'événement dans le journal binaire, et des faux positifs peuvent se produire. Par exemple, lorsque la bibliothèque principale exécute une transaction volumineuse, son exécution prend beaucoup de temps. Après l'avoir reçue de la bibliothèque esclave, elle compare l'horodatage et constate qu'elle a été retardée, et la valeur SMB augmentera instantanément. La valeur de Read_Master_Log_Pos-Exec_Master_Log_Pos n'est pas totalement fiable. Désormais, pt-heartbeat peut nous aider à résoudre ce problème.

Jetons un coup d'œil au principe de pt-heartbeat :

pt-heartbeat créera une table sur le maître, mettra à jour les champs de la table à une certaine fréquence et écrira dans le tableau Entrez l'horodatage actuel, puis comparez l'horodatage de la bibliothèque esclave avec l'horodatage de la machine où se trouve pt-heartbeat pour déterminer le délai maître-esclave.

En fait, il y a un problème ici. Si pt-heartbeat est déployé dans la bibliothèque esclave, il doit garantir que l'heure des machines maître et esclave est synchronisée. Ceci est généralement réalisé par la synchronisation automatique du système. l'heure chaque jour. Si pt-heartbeat est déployé dans la bibliothèque principale, ce problème ne se posera pas. En fait, je pense personnellement qu'une meilleure façon est de comparer les horodatages de cette table dans la base de données maître-esclave pour déterminer que le délai est plus fiable. Bien sûr, cela doit également prendre en compte le problème de requête maître-esclave.

Jetons un coup d'œil à l'utilisation de base :

Créez d'abord le tableau :

[root@mxqmongodb2 bin]# ./pt-heartbeat --host=172.16.16.35 --port=3306 --user=root --password=123456 --database=test --update --create-table --daemonize

Copier après la connexion

Jetez un œil à la structure de la table :

mysql> desc heartbeat;+-----------------------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+---------------------+------+-----+---------+-------+
| ts | varchar(26) | NO | | NULL | |
| server_id | int(10) unsigned | NO | PRI | NULL | |
| file | varchar(255) | YES | | NULL | |
| position | bigint(20) unsigned | YES | | NULL | |
| relay_master_log_file | varchar(255) | YES | | NULL | |
| exec_master_log_pos | bigint(20) unsigned | YES | | NULL | |
+-----------------------+---------------------+------+-----+---------+-------+6 rows in set (0.01 sec)
mysql> select * from heartbeat\G*************************** 1. row ***************************ts: 2017-06-23T09:27:49.001580server_id: 353306file: mysql-bin.000016position: 299837221relay_master_log_file: NULL
exec_master_log_pos: NULL1 row in set (0.00 sec)

Copier après la connexion

Regardons de plus près le lien de la base de données et trouvons cela il y a une opération de mise à jour :

UPDATE `test`.`heartbeat` SET ts='2017-06-23T09:32:47.001330', file='mysql-bin.000016', position='29

Copier après la connexion

En fait, l'opération suivante démarre simplement un processus et met à jour en permanence la table des battements de cœur pour obtenir les dernières données.

[root@mxqmongodb2 bin]# ./pt-heartbeat --host=172.16.16.35 --port=3306 --user=root --password=123456 --database=test --update --daemonize

Copier après la connexion

Ensuite, nous démarrons le processus de surveillance, qui est constamment actualisé :

[root@mxqmongodb2 bin]# ./pt-heartbeat -D test --monitor -h 172.16.16.34 -uroot -P3306 -p1234560.00s [ 0.00s, 0.00s, 0.00s ]0.00s [ 0.00s, 0.00s, 0.00s ]0.00s [ 0.00s, 0.00s, 0.00s ]0.00s [ 0.00s, 0.00s, 0.00s ]0.00s [ 0.00s, 0.00s, 0.00s ]

Copier après la connexion

Nous avons précisé qu'il n'y a pas de délai. Commençons le test de résistance maintenant et jetons un autre coup d'oeil :

[root@mxqmongodb2 tpcc-mysql]# ./tpcc_start -h127.0.0.1 -P3306 -d tpcc -u root -p123456 -w 10 -c 20 -r 10 -l 600

Copier après la connexion

Observez le retard :

0.71s [ 0.68s, 0.16s, 0.05s ]1.71s [ 0.71s, 0.17s, 0.06s ]0.85s [ 0.72s, 0.17s, 0.06s ]0.93s [ 0.74s, 0.18s, 0.06s ]0.00s [ 0.74s, 0.18s, 0.06s ]0.82s [ 0.73s, 0.18s, 0.06s ]0.66s [ 0.75s, 0.18s, 0.06s ]0.00s [ 0.75s, 0.18s, 0.06s ]0.88s [ 0.74s, 0.18s, 0.06s ]1.00s [ 0.74s, 0.19s, 0.06s ]

Copier après la connexion

Nous pouvons voir quand il s'agit latence, nous pouvons rediriger ces résultats de sortie vers un fichier pour surveiller la latence maître-esclave, ce qui est également très efficace.

Nous arrêtons maintenant manuellement sql_thread de la base de données :

mysql> stop slave sql_thread;
Query OK, 0 rows affected (0.03 sec)

Copier après la connexion

Ensuite, regardez le résultat :

53.00s [ 23.85s, 6.77s, 4.20s ]54.00s [ 24.75s, 6.94s, 4.26s ]55.00s [ 25.67s, 7.12s, 4.32s ]56.00s [ 26.60s, 7.30s, 4.39s ]57.00s [ 27.55s, 7.48s, 4.45s ]58.00s [ 28.52s, 7.67s, 4.51s ]59.00s [ 29.50s, 7.86s, 4.58s ]60.00s [ 30.50s, 8.05s, 4.65s ]61.00s [ 31.50s, 8.23s, 4.71s ]62.00s [ 32.50s, 8.42s, 4.78s ]63.00s [ 33.50s, 8.61s, 4.85s ]64.00s [ 34.50s, 8.80s, 4.92s ]65.00s [ 35.50s, 8.98s, 5.00s ]

Copier après la connexion

On constate qu'il continue d'augmenter et que l'intervalle est d'une seconde. On recommence ce sql_thread, et la bibliothèque esclave rattrape rapidement la bibliothèque principale.

Ou nous pouvons surveiller à travers ce qui suit :

[root@mxqmongodb2 bin]# ./pt-heartbeat -D test --check -h 172.16.16.34 -uroot -P3306 -p1234561.00[root@mxqmongodb2 bin]# ./pt-heartbeat -D test --check -h 172.16.16.34 -uroot -P3306 -p1234560.00

Copier après la connexion

Il renverra directement un deuxième numéro retardé, c'est également relativement fiable. Nous pouvons directement utiliser cette valeur pour la surveillance.

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!