DTCC2017〡騰訊云CDB的核彈頭:TXSQL的研發、實踐和未來(2)
MySQL redo log是一個順序寫的單緩沖區,log_sys->mutex鎖資源竟爭激烈,在事務落盤的過程中對LSN相關的讀、寫都被阻塞,為了解決 log_sys->mutex的鎖竟爭問題,引入雙緩沖區機制&w_mutex鎖,在flush redo log 的過程中釋放log_sys->mutex,繼續持有log_sys->w_mutex,從而阻塞寫,不阻塞LSN相關的讀操作,flush完成后釋放w_mutex;從而提升并發性,提升性能。

圖3
TXSQL性能數據對比

讀性能數據對比

寫性能數據對比

讀寫混合數據對比
TXSQL功能開發
在TXSQL并行復制方面,MySQL并行復制存在的問題:在實際的應用環境中,實例中往往只有一個 Database,導致 relay log 中的事務大部分會分到同一個 worker 線程中,造成備庫的性能低下,當主庫的性能超過備庫的單線程執行的性能時,就會出現延遲,對只讀實例產生影響。
TXSQL并行復制存在的優化
為了解決上述問題,TXSQL 添加了另外一種分發方式,即基于表粒度的分發,為了實現基于表粒度的分發,TXSQL 對于不同的實現,進行了不同的處理:
當binlog_row_format= ROW 時, 調用 get_slave_worker 直接進行分發;
當 binlog_row_format= statement 時,則需要對語句先進行調用 mysql_parse 對語句進行解析,然后再做分發。
TXSQL強同步支持
原生 semi-sync 存在著以下問題:
semi-sync 在時間超過 rpl_semi_sync_master_timeout 會退化為異步;
采用 select 進行監聽,當句柄值大于 1024 時則會出現異常,詳情可參考 bug#79865;
在 after commit 后等待 ACK 容易出現幻讀的問題;
TXSQL 強同步支持:
優化半同步,增加ack線程,收發并行化;
修正select時fd超過1024導致異常的bug,改為poll;
在半同步基礎上實現強同步,一直hold住直到收到ack;
修改同步方式時,喚醒正在等待的用戶線程,繼續等待或者退出;
增加一些狀態,用于展示當前等待的情況(正在等待的binlog位點,已等待時間);
對于主多 binlog 備少 binlog 的情況進行特殊的處理,以保證雙寫的情況不會發生;
TXSQL云上實踐
XX游戲數據庫優化案例
問題現象:性能不能滿足業務要求,游戲業務邏輯 TPS 不達標;在壓力達到一定程度時,CPU 不能充分利用,idle 較高;性能抖動較為明顯; thread running 過高,系統負載較高;系統 IO 壓力較小,IO 沒有問題;
問題排查:
pt-pmp & pstack & mysql 命令進行問題排查,發現以下問題:
?????投稿郵箱:jiujiukejiwang@163.com ??詳情訪問99科技網:http://www.hacbq.cn
推薦資訊
























