Percona-tookit學習筆記（六）

• 2019 年 10 月 5 日
• 筆記

pt-variable-advisor

功能：

    分析mysql的參數變量，並對可能存在的問題提出建議

例1：

    pt-variable-advisor --user=root--password=root localhost

例2：

    pt-variable-advisor --user=root--password=root  --source-of-variablesmy.cnf

# pt-variable-advisor --user=root--password=root localhost > pt-variables-adv.log

結果如下：

說明: 下面的只是提示，各位根據自己的業務需求來改即可。

# NOTE connect_timeout: A largevalue of this setting can create a denial of service vulnerability.

# WARN delay_key_write: MyISAMindex blocks are never flushed until necessary.   【設置delay_key_write = OFF 】

# NOTE log_warnings-2:Log_warnings must be set greater than 1 to log unusual events such as abortedconnections.

【可設置log_warnings = 2 】

# NOTE max_binlog_size: Themax_binlog_size is smaller than the default of 1GB.  【設置max_binlog_size = 1G】

# NOTE read_buffer_size-1: Theread_buffer_size variable should generally be left at its default unless anexpert determines it is necessary to change it.

# NOTE read_rnd_buffer_size-1: Theread_rnd_buffer_size variable should generally be left at its default unless anexpert determines it is necessary to change it.

# WARN slave_net_timeout: Thisvariable is set too high.    【根據這條提示，可以設置slave_net_timeout = 60】

# NOTE sort_buffer_size-1: Thesort_buffer_size variable should generally be left at its default unless anexpert determines it is necessary to change it. 【可以修改下innodb_data_file_path =ibdata1:1G：autoextend：max:2G】

# NOTE innodb_data_file_path:Auto-extending InnoDB files can consume a lot of disk space that is verydifficult to reclaim later.

# WARN key_buffer_size: The keybuffer size is set to its default value, which is not good  for most production systems. 【根據這條提示，可以設置key_buffer_size = 100M】

# WARN expire_logs_days: Binarylogs are enabled, but automatic purging is not enabled.【可設置expire_logs_days = 20解決】

# NOTE innodb_flush_method: Mostproduction database servers that use InnoDB should set innodb_flush_method toO_DIRECT to avoid double-buffering, unless the I/O system is very lowperformance. 【根據這條提示，可以設置innodb_flush_method =O_DIRECT】

# NOTE max_relay_log_size: Acustom max_relay_log_size is defined.

# WARN myisam_recover_options:myisam_recover_options should be set to some value such as BACKUP,FORCE toensure that table corruption is noticed.

# WARN sync_binlog: Binary loggingis enabled, but sync_binlog isn't configured so that every transaction isflushed to the binary log for durability. 【根據這條提示，為了更高的數據安全性，可以設置sync_binlog = 1】

pt-deadlock-logger

作用：

    收集和保存mysql上最近的死鎖信息，可以直接打印死鎖信息和存儲死鎖信息到數據庫中，死鎖信息包括發生死鎖的服務器、最近發生死鎖的時間、死鎖線程id、死鎖的事務id、發生死鎖時事務執行了多長時間等等非常多的信息。

範例1：打印本地mysql的死鎖信息

# pt-deadlock-logger  --user=root --password=root h=localhost–print

範例2：將本地的mysql死鎖信息記錄到數據庫的表中，也打印出來

# pt-deadlock-logger  --user=root --password=root h=localhost--print D=test,t=deadlocks

pt-fk-error-logger

作用：

    記錄外鍵錯誤信息。

    通過SHOW INNODB STATUS提取和保存mysql數據庫最近發生的外鍵錯誤信息。可以通過參數控制直接打印錯誤信息或者將錯誤信息存儲到數據庫的表中。

pt-mext

作用：

    Lookat many samples of MySQL "SHOW GLOBAL STATUS" side-by-side

    –relative  縮寫為 -r  Subtract each column from the previous column

 範例：

    獲取系統消息(結果和show global status一樣)

    #pt-mext -r -- mysqladmin ext -i10 -c3 --user=root --password=root

pt-heartbeat

說明：

    監控mysql複製延遲。測量複製落後主mysql或者主PostgreSQL多少時間，你可以使用這個腳本去更新主或者監控複製。

    pt-heartbeat measures replication lag on aMySQL or PostgreSQL server.  You can useit to update a master or monitor a replica. If possible, MySQL connectionoptions are read from your .my.cnf file.

在主節點執行pt-heartbeat這個命令。

原理：

    pt-heartbeat通過真實的複製數據來確認mysql和postgresql複製延遲，這個避免了對複製機制的依賴，從而能得出準確的落後複製時間。

    包含兩部分：

       第一部分在主上pt-heartbeat的–update線程會在指定的時間間隔更新一個時間戳；

       第二部分是pt-heartbeat的–monitor線程或者–check線程連接到從上檢查複製的心跳記錄（前面更新的時間戳），並和當前系統時間進行比較，得出時間的差異。

格式：

    pt-heartbeat-D test –update -h master-server –daemonize

    pt-heartbeat-D test –monitor -h slave-server

    pt-heartbeat-D test –check h=slave-server

實例：

1、在主節點192.168.2.11執行啟動更新test.heartbeat表操作：

    #pt-heartbeat -D test --update --user=root --password=root -h 192.168.2.11--create-table –daemonize

2、在主節點192.168.2.11執行啟動監控複製在slave上的落後程度（會一直監控）：

    #pt-heartbeat -D test --monitor --user=root --password=root  -h 192.168.2.12   結果如下圖所示：

3、檢查Slave節點落於Master多長時間

    #pt-heartbeat -D test --check --user=root --password=root h=192.168.2.12        結果如下圖所示,0表示沒有延遲：

4、監控完畢，記得關閉第一步的pt-heartbeat後台進程

    #kill -9 `ps aux|grep pt-heartbeat|grep -v grep|awk '{print $2}'`

pt-slave-delay

作用：

    設置從服務器落後於主服務器指定時間。

    Makea MySQL slave server lag behind its master

    pt-slave-delaystarts and stops a slave server as needed to make it lag behind the master.TheSLAVE_DSN and MASTER_DSN use DSN syntax, and values are copied from theSLAVE_DSN to the MASTER_DSN if omitted.

原理：

    通過啟動和停止複製sql線程來設置從落後於主指定時間。默認是基於從上relay日誌的二進制日誌的位置來判斷，因此不需要連接到主服務器，如果IO進程不落後主服務器太多的話，這個檢查方式工作很好，如果網絡通暢的話，一般IO線程落後主通常都是毫秒級別。一般是通過–delay and–delay"+"–interval來控制。–interval是指定檢查是否啟動或者停止從上sql線程的頻繁度，默認的是1分鐘檢查一次。

例：

    使主從之間延遲1分鐘，每隔15秒檢測一次，運行10分鐘

    #pt-slave-delay --user=root --password=root --delay 1m --interval 15s --run-time10m --host=192.168.2.12

    如果不加–run-time 參數，這個命令會一直在前台運行下去

    –daemonize表示以後台守護進程執行

    –quiet表示靜默執行

    –port=3306  指明端口

    說明：用了這個工具的話，slave節點執行show slave statusG可以看到從節點的Slave_SQL_Running狀態是在Yes和No之間不斷切換的。

pt-slave-find

作用：找到主節點下的所有從節點

原理：連接mysql主服務器並查找其所有的從，然後打印出所有從服務器的層級關係

語法：pt-slave-find –user=xx –password=xxx –host=master_ip

示例：

# pt-slave-find --user=root --password=root --host=192.168.2.11

pt-slave-restart

作用：

    監視mysql複製錯誤，當複製停止的時候嘗試重啟mysql複製。Watch and restart MySQLreplication after errors

示例：

    監視IP為192.168.2.12的從節點，跳過1個錯誤

    #pt-slave-restart –user=root –password=root –host=192.168.2.12 –skip-count=1

    監視192.168.2.12的從節點，跳過錯誤代碼為1062的錯誤。

    #pt-slave-restart –user=root –password= root –host=192.168.2.12 –error-numbers=1062

    –verbose  顯示詳細信息

pt-table-checksum

作用：

    檢查複製的完整性    VerifyMySQL replication integrity

原理：

    pt-table-checksum在主上執行檢查語句在線檢查mysql複製的一致性，生成replace語句，然後通過複製傳遞到從，再通過update更新master_src的值。通過檢測從上this_src和master_src的值從而判斷複製是否一致。

注意：

    使用的時候選擇業務低谷的時候運行，因為運行的時候會造成表的部分記錄鎖定。此外，還要確保從庫的IO/SQL線程都是YES狀態的。

    使用–max-load來指定最大的負載情況，如果達到那個負載這個暫停運行。如果發現有不一致的數據，可以使用pt-table-sync工具來修復。

示例：比較hellodb數據庫下所有的表同步是否一致，結果顯示hellodb庫所有的表的校驗和

首先，我們在Slave節點修改下hellodb.students一條數據，模擬出主從之間數據不一致的情況。

step1、在主節點執行：

# pt-table-checksum--nocheck-replication-filters   --databases=hellodb--replicate=hellodb.checksums   --host=192.168.2.11 --user=root--password=root --port 3306   --no-check-binlog-format

參數說明：

–host=主節點的IP地址

–no-check-binlog-format        :因為我們的日誌用的MIXED格式，所有這裡要加上不檢查複製的binlog模式

–replicate-check-only          :只顯示不同步的信息【對於需要比較大量數據庫時候排除干擾的條目,很有用】

–replicate=db_name.tb_name     ：把checksum的信息寫入到指定表中，建議直接寫到被檢查的數據庫當中。

–databases=db1,db2             ：指定需要被檢查的數據庫，多個則用逗號隔開。

–tables=                       ：指定需要被檢查的表，多個用逗號隔開[不寫就是檢查給出的庫里涉及到的所有表]

h=127.0.0.1   ：Master的地址

u=root        ：用戶名

p=123456      ：密碼

P=3306        ：端口

執行結果如下圖所示，我們可以看到有一個DIFFS：

TS            ：完成檢查的時間。

ERRORS        ：檢查時候發生錯誤和警告的數量。

DIFFS         ：0表示一致，1表示不一致。當指定–no-replicate-check時，會一直為0，當指定–replicate-check-only會只顯示不同的信息。

ROWS          ：表的行數。

CHUNKS        ：被劃分到表中的塊的數目。

SKIPPED       ：由於錯誤或警告或過大，則跳過塊的數目。

TIME          ：執行的時間。

TABLE         ：被檢查的表名。

說明：如果加上–replicate-check-only 參數的話，只會顯示有不同的表的地方。如下圖：

另外，操作完成後，會在hellodb庫下生成一個checksums表。

step2、到Slave節點上查詢下結果如下

[因為在Master節點查看的話this_crc和master_crc是一樣的，沒比較的意義]：

MySQL [test] >select * fromhellodb.checksumsG  可以看到主從的students的行數不一樣

MySQL [test] >select * fromhellodb.checksums;

pt-table-sync

功能：

    高效地同步MySQL Table表數據。他可以做單向和雙向同步的表數據。他可以同步單個表，也可以同步整個庫。它不同步表結構、索引、或任何其他模式對象。所以在修復一致性之前需要保證他們表存在。

說明：

    為了安全起見，建議修改前先備份數據。

原理：

    總是在主上執行數據的更改，再同步到從上，不會直接更改成從的數據，在主上執行更改是基於主上現在的數據，不會更改主上的數據。注意使用之前先備份你的數據，避免造成數據的丟失.執行execute之前最好先換成–print或–dry-run查看一下會變更哪些數據。

範例1：同步從的test庫的aaa表到主的，在執行之前可以用–execute參數換成–print來查看會變更什麼東西，後面那個主機必須是master

pt-table-sync--user=root --password=root h=192.168.2.12,D=hellodb,t=students h=192.168.2.11 --print

pt-table-sync --user=root--password=root h=192.168.2.12,D=hellodb,t=students h=192.168.2.11 --execute

範例2：將主的test數據庫同步到從節點192.168.2.12，使從上具有一樣的數據   [在主節點執行該命令]

pt-table-sync –sync-to-master–user=root –password=root  h=192.168.2.12 –database test –execute

範例3：只同步指定的表[在主節點執行該命令]

pt-table-sync –sync-to-master–user=root –password=root  h=192.168.2.12,D=test,t=aaa –execute

範例4：根據pt-table-checksum的結果進行數據同步，使得從節點數據能和主節點數據一致  [在主節點執行該命令]

pt-table-sync –replicatetest.checksums –user=root –password=root  h=192.168.2.11 –execute

範例5：根據pt-table-checksum使從的數據和主的數據一致

pt-table-sync –replicatetest.checksums –user=root –password=root 

–sync-to-master h=192.168.2.12,D=test,t=aaa–execute

同步host1上的db.tbl到host2:

# pt-table-sync –executeh=host1,D=db,t=tbl h=host2

同步host1上的所有表到host2和host3:

# pt-table-sync –execute host1host2 host3

Same as above butonly resolve differences on slave1:

# pt-table-sync –sync-to-master –replicatetest.checksum slave1 –execute

Sync master2 in amaster-master replication configuration, where master2』s copy of db.tbl isknown or suspected to be incorrect:

# pt-table-sync –execute–sync-to-master h=master2,D=db,t=tbl

下面補充一個很不錯的主從數據不一致的數據修復案例：

step0、修改從節點數據讓主從不一致

> delete from hellodb.studentswhere StuID=24;   # 在從節點執行刪除行操作

step1、發現主從數據不一致 [該命令在主節點執行]

# pt-table-checksum--nocheck-replication-filters --databases=hellodb   --replicate=test.checksums   --host=192.168.2.11 --user=root--password=root --port 3306   --no-check-binlog-format

step2、輸出不一致的數據條目  [該命令在主節點執行]

# pt-table-sync --replicate=test.checksums h=192.168.2.11,u=root,p=root h=192.168.2.12,u=root,p=root --print

step3、修復操作，確保主從數據一致 [該命令在主節點執行]

# pt-table-sync--replicate=test.checksums  h=192.168.2.11,u=root,p=rooth=192.168.2.12,u=root,p=root --execute

step4、再次檢查主從數據是否一致

# pt-table-checksum--nocheck-replication-filters --databases=hellodb   --replicate=test.checksums   --host=192.168.2.11 --user=root--password=root --port 3306   --no-check-binlog-format

這樣就數據同步了，如果不放心的話可以到從節點去看下hellodb.students的數據是否和主節點的一致了。