Beispielcode zu pt-heartbeat (Percona Toolkit)-MySQL-Tutorial-php.cn

pt-heartbeat ist ein Percona-Tool zur Überwachung der Master-Slave-Latenz. Der Großteil unserer MySQL-Architektur basiert immer noch auf Master-Slave-Replikation, wie z. B. MHA, MMM, Keepalived und anderen Lösungen. In der Master-Slave-Umgebung sind wir sehr besorgt über das Master-Slave-Verzögerungsproblem. Im Allgemeinen führen wir die folgenden Anweisungen in der Slave-Bibliothek aus:

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)

Nach dem Login kopieren

Sie können den Status von Master und Slave deutlich erkennen. Im Allgemeinen überwachen wir den Status der folgenden beiden Prozesse, um festzustellen, ob ein Fehler in der Master-Slave-Verzögerung vorliegt:

Slave_IO_Running: Ja

Slave_SQL_Running: Ja

Was die Master-Slave-Verzögerung anbelangt, können wir die meiste Überwachung über SMB (Seconds_Behind_Master) durchführen. aber das ist nicht sehr zuverlässig. Oder wir können den Unterschied zwischen Read_Master_Log_Pos-Exec_Master_Log_Pos überwachen, um zu sehen, ob es eine Verzögerung in der Slave-Bibliothek und ob es eine bestimmte Verzögerung in der Master-Bibliothek gibt. Aber auch dieser ist nicht ganz perfekt. Schauen Sie sich zunächst SMB an. Wie wird dieser Parameter durch Vergleich des aktuellen Zeitstempels des Servers mit dem Ereigniszeitstempel im Binärprotokoll ermittelt? Wenn die Hauptbibliothek beispielsweise eine große Transaktion ausführt, dauert die Ausführung lange. Nach dem Empfang von der Slave-Bibliothek vergleicht sie den Zeitstempel und stellt fest, dass sie verzögert wurde, und der SMB-Wert wird sofort erhöht. Der Wert von Read_Master_Log_Pos-Exec_Master_Log_Pos ist nicht vollständig zuverlässig. Jetzt kann uns pt-heartbeat helfen, dieses Problem zu lösen.

Werfen wir einen Blick auf das Prinzip von pt-heartbeat:

pt-heartbeat erstellt eine Tabelle auf dem Master, aktualisiert die Felder der Tabelle in einer bestimmten Zeitfrequenz und schreibt darauf Geben Sie in der Tabelle den aktuellen Zeitstempel ein und vergleichen Sie dann den Zeitstempel der Slave-Bibliothek mit dem Zeitstempel der Maschine, auf der sich pt-heartbeat befindet, um die Master-Slave-Verzögerung zu bestimmen.

Tatsächlich liegt hier ein Problem vor. Wenn pt-heartbeat in der Slave-Bibliothek eingesetzt wird, muss sichergestellt werden, dass die Zeit der Master- und Slave-Maschinen synchronisiert wird. Dies wird normalerweise durch die automatische Synchronisierung erreicht die Zeit jeden Tag. Wenn pt-heartbeat in der Hauptbibliothek bereitgestellt wird, tritt dieses Problem nicht auf. Tatsächlich bin ich persönlich der Meinung, dass es besser ist, die Zeitstempel dieser Tabelle in der Master-Slave-Datenbank zu vergleichen, um festzustellen, ob die Verzögerung zuverlässiger ist. Dabei muss natürlich auch das Problem der Master-Slave-Abfrage berücksichtigt werden.

Werfen wir einen Blick auf die grundlegende Verwendung:

Erstellen Sie zuerst die Tabelle:

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

Nach dem Login kopieren

Schauen Sie sich die Tabellenstruktur an:

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)

Nach dem Login kopieren

Schauen wir uns den Datenbanklink genauer an und finden ihn heraus Es gibt einen Aktualisierungsvorgang:

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

Nach dem Login kopieren

Tatsächlich startet der folgende Vorgang lediglich einen Prozess und aktualisiert kontinuierlich die Heartbeat-Tabelle Holen Sie sich die neuesten Daten.

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

Nach dem Login kopieren

Als nächstes starten wir den Überwachungsprozess, der ständig aktualisiert wird:

[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 ]

Nach dem Login kopieren

Wir haben angegeben, dass es keine Verzögerung gibt. Beginnen wir jetzt mit dem Stresstest und schauen Sie noch einmal nach:

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

Nach dem Login kopieren

Beobachten Sie die Verzögerung:

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 ]

Nach dem Login kopieren

Wir können sehen, wann es darum geht Latenz können wir diese Ausgabeergebnisse in eine Datei umleiten, um die Master-Slave-Latenz zu überwachen, was ebenfalls sehr effektiv ist.

Wir stoppen jetzt sql_thread manuell aus der Datenbank:

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

Nach dem Login kopieren

Dann schauen Sie sich die Ausgabe an:

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 ]

Nach dem Login kopieren

Es wurde festgestellt, dass es immer weiter zunimmt und das Intervall eine Sekunde beträgt. Wir starten diesen sql_thread erneut und die Slave-Bibliothek schließt schnell zur Hauptbibliothek auf.

Oder wir können Folgendes überwachen:

[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

Nach dem Login kopieren

Er wird direkt eine verzögerte zweite Nummer zurückgeben, das ist auch relativ zuverlässig. Wir können diesen Wert direkt zur Überwachung verwenden.

Das obige ist der detaillierte Inhalt vonBeispielcode zu pt-heartbeat (Percona Toolkit). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!