国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

基于行事件導致從庫運行緩慢及解決方法

IT那活兒 / 2506人閱讀
基于行事件導致從庫運行緩慢及解決方法

點擊上方“IT那活兒”公眾號,關注后了解更多內容,不管IT什么活兒,干就完了!!!




問題現象
最近,在處理了一個從庫延遲問題,在分析期間,發現從庫 SQL 線程在處理來自主庫二進制日志的基于行的事件時無法跟上。
例如:
1)從庫復制狀態
mysql> SHOW SLAVE STATUSG
*************************** 1. row ***************************
...
Master_Log_File: binlog.0000185
Read_Master_Log_Pos: 86698585
...
Relay_Master_Log_File: binlog.0000185
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
...
Exec_Master_Log_Pos: 380
Relay_Log_Space: 85699128
...
Master_UUID: 98974e7f-2fbc-18e9-72cd-07003817585c
...
Retrieved_Gtid_Set: 98974e7f-2fbc-18e9-72cd-07003817585c:1055-1057
Executed_Gtid_Set: 7f42e2c5-3fbc-16e7-7fb8-05003715789a:1-2,
98974e7f-2fbc-18e9-72cd-07003817585c:1-1056
...
SQL 線程的 processlist 狀態可以是以下其中之一: 
  • 從中繼日志中讀取事件;

  • System lock 或是其他的一些狀態。

2)目前

mysql> SHOW PROCESSLIST;
+----+-----------------+-----------------+------+---------+------+----------------------------------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+-----------------+-----------------+------+---------+------+----------------------------------+------------------+
...
|
  4 | system user |                 | NULL | Connect | 268 | Reading event from the relay log | NULL |
...
+----+-----------------+-----------------+------+---------+------+----------------------------------+------------------+



導致此類行為的原因以及注意事項
當 SQL 線程應用基于行的事件更改時,它必須找到被更新的確切行。使用主鍵,因為只有一行才可能具有相同的主鍵。
但是,如果從庫表上沒有主鍵,SQL 線程必須搜索整個表才能找到要更新或刪除的行。它重復搜索每個更新的行。這種搜索會占用大量資源(CPU 占用率最高可達 100%),又會導致從庫延遲。
對于 InnoDB 表,不能使用沒有主鍵的表的聚集索引來避免在整個表中搜索更新或刪除的行。
“隱藏”主鍵僅對每個 MySQL 實例是唯一的,因此主庫和從庫通常不會對同一行的“隱藏”主鍵具有相同的值。



如何解決這個問題
最好的解決方案是確保所有表都有一個主鍵這不僅確保 SQL 線程可以輕松找到需要更新或刪除的行,因為它確保所有行都是唯一的。
如果無法在邏輯上為表添加自然主鍵,一個潛在的解決方案是添加一個自增無符號整數列作為主鍵。
通過下面查詢找到沒有主鍵的表:
SELECT tables.table_schema, tables.table_name, tables.table_rows
FROM information_schema.tables
LEFT JOIN (
SELECT table_schema, table_name
FROM information_schema.statistics
GROUP BY table_schema, table_name, index_name
HAVING
SUM(
CASE WHEN non_unique = 0 AND nullable != YES THEN 1 ELSE 0 END
) = COUNT(*)
) puks
ON tables.table_schema = puks.table_schema AND tables.table_name = puks.table_name
WHERE puks.table_name IS NULL
AND tables.table_schema NOT IN (mysql, information_schema, performance_schema, sys)
AND tables.table_type = BASE TABLE AND engine=InnoDB;
如果應用程序端或者業務系統上有很多關聯,更改后需要測試的未知應用程序行為等,并不可以立即將主鍵添加到表中。
在這種情況下,一個短期的解決方案是更改從庫使用的搜索算法,以定位由基于行的事件更改的行。
搜索算法是使用 MySQL 5.6 及更高版本中可用的 slave_rows_search_algorithms 選項設置的。默認值是盡可能使用索引掃描,否則使用表掃描。
但是,對于沒有主鍵的表使用散列掃描,這會導致 SQL 線程臨時緩存散列以減少搜索整個表的開銷。slave_rows_search_algorithms的值可以使用以下方法動態更改:
mysql> SET GLOBAL slave_rows_search_algorithms = INDEX_SCAN,HASH_SCAN;
使用哈希掃描時要注意的一件事是,哈希僅在一個基于行的事件中重復使用。(每個基于行的事件可能對主庫同一SQL 語句的同一表中的幾行進行更改)。
復制主服務器上的 binlog_row_event_max_size 選項控制基于行的事件的最大大小。默認的最大事件大小為 8kB。

意味著切換到哈希掃描只會在以下情況下提高 SQL 線程的性能:

  • 如果對大行(例如,使用 blob 或文本數據)執行更新或刪除,增加主庫上binlog_row_event_max_size的值可能會有所幫助 。

    只能在 MySQL 配置文件中設置 binlog_row_event_max_size  ,重置該值需要重啟數據庫。

總結:即使啟用哈希掃描可以提高從庫的性能,但永久的解決方案是為每個表添加顯式主鍵,這種模式可以避免許許多多的問題。


END




本文作者:高智飛(上海新炬王翦團隊)

本文來源:“IT那活兒”公眾號

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/129433.html

相關文章

  • 跨云遷移過程中的數據同步一致性校驗實踐(一)

    摘要:通過對一些客戶的跨云遷移過程進行總結,發現普遍存在的挑戰有三點數據完整性和一致性挑戰。簡而言之,跨云遷移過程中的數據一致性主要就集中在存量數據的遷移如何保證一致。前言隨著互聯網業務發展對容災以及對訪問加速、多供應商成本控制等需求的產生,互聯網公司的多云部署和跨云遷移逐漸成為剛需,而在此過程中,最困擾運維和研發人員的就是數據的遷移和同步。俗語說 上屋搬下屋,搬灑一籮谷 ,在業務的遷移過程中一旦...

    Tecode 評論0 收藏0

發表評論

0條評論

IT那活兒

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<