轉移動雲基於MySQL Galera的PXC運維實戰

時間 2019-11-06

標籤移動基於 mysql galera pxc 實戰欄目無線简体版

原文原文鏈接

##sample 1 : mysql 監控php

1.phpadmin 比較簡單，適合上手python

2.mysql_web python 寫的，mysql

https://github.com/ycg/mysql_web/ios

mysql monitor web - MySQL實時監控

安裝環境：

基於python2.7.11開發的
安裝MySQL數據庫
安裝python第三方包

    #更新setuptools wget http://pypi.python.org/packages/source/s/setuptools/setuptools-0.6c11.tar.gz tar -zxvf setuptools-0.6c11.tar.gz cd setuptools-0.6c11 python setup.py build python setup.py install #更新pip wget https://pypi.python.org/packages/11/b6/abcb525026a4be042b486df43905d6893fb04f05aac21c32c638e939e447/pip-9.0.1.tar.gz#md5=35f01da33009719497f01a4ba69d63c9 tar -zxvf pip-9.0.1.tar.gz cd pip-9.0.1 python setup.py build python setup.py install #安裝python包 pip install flask flask-login gevent threadpool pymysql DBUtils six packaging appdirs mysql-replication sqlparse paramiko

在setting.py設置MySQL_Host相關帳戶信息

MySQL_Host = host_info.HoseInfo(host="192.168.11.128", port=3306, user="yangcg", password="yangcaogui", remark="Monitor")

導入sql/table.sql的SQL腳本
添加MySQL數據庫用戶

insert into host_infos (host, port, user, password, remark) values ("192.168.11.129", 3306, "yangcg", "yangcaogui", "Master"), ("192.168.11.130", 3306, "yangcg", "yangcaogui", "Slave");

添加系統登陸帳號

insert into mysql_web.mysql_web_user_info (user_name, user_password)values("yangcaogui", md5("123456"));

啓動mysql web系統

    #前臺啓動： python mysql_web.py runserver #後臺啓動 nohup python mysql_web.py runserver &

若是要監控慢查詢還要進行幾步配置

支持的功能:

mysql tps qps table_cache handler監控
支持對innodb各類status進行監控
支持對show engine innodb status分析
支持對複製進行監控
支持對錶空間進行分析
支持對os基本監控
支持收集慢查詢監控
支持對thread進行完整分析
支持實時的圖表顯示
支持對數據庫用戶帳號的查詢
支持登陸驗證，未登陸不容許查看其它任何界面
支持半同步複製的實時監控

完成的腳本:

binlog_bk.py - 實現使用mysqlbinlog對binlog日誌進行備份
binlog_sync.py - 實現對binlog進行分析，能夠把數據同步到另外一個實例中
binlog_util.py - 基於mysql-replication的binlog分析，可生成回滾SQL，實現誤操做的閃回
binlog_util_new.py - 實現對binlog文件的分析，可生成回滾SQL
bk_xtrabackup.py - 實現對xtrabackup的備份封裝，能夠增量和全備
bk_recovery_xtrbackup.py - 是基於bk_xtrabackup.py實現的備份恢復，能夠遠程和本地恢復
collect_mysql_status_log.sh - 實現對mysql指定時間段的日誌收集，有助於排除問題
mysql_auto_install.py - 實現mysql的遠程自動安裝
mysql_replication_repair.py - 實現對slave出現1032和1062錯誤的自動修復功能
mysql_slow_log.sh - 基於pt工具的慢查詢收集腳本，須要和mysql_web一塊兒使用
bk_xtrabackup_remote.py - 支持遠程備份，比較強大

聯繫方式

QQ: 779647966
Email: ycg166911@163.com

###########git

https://mp.weixin.qq.com/s/YTwdVRh_Uhtf3bn2MO2H_Qgithub

做者介紹web

劉書浩，「移動雲」DBA，負責「移動雲」業務系統的數據庫運維、標準化等工做；擅長MySQL技術領域，熟悉MySQL複製結構、Cluster架構及運維優化；具備自動化運維經驗，負責「移動雲」數據庫管理平臺的搭建。算法

前言sql

在衆多的MySQL開源軟件中，Galera是很是有特點的，它的特色及優點是具備良好的併發性和一致性。Galera Cluster的主要用途是爲MySQL提供一致性的集羣化解決方案，以一個dlopenable通用複製庫的形式提供給MySQL，並經過自身的Write-Set提供複製服務，實現MySQL的多線程並行複製。此外，它自帶集羣節點管理機制，能夠主動監測集羣節點狀態，自動管理有問題的數據節點，同時也能夠實現集羣的多點寫入和平滑擴容。它對待事務的行爲時，要麼在全部節點上執行，要麼都不執行，這種實現機制決定了它對待一致性的行爲很是嚴格，可以很是完美地保證MySQL集羣的數據一致性。shell

目前，對Galera Cluster的封裝有兩個，雖然名稱不一樣，但實質都是同樣的，使用的都是Galere羣集。一個是MySQL的創始人Monty在本身全新的MariaDB上實現的MariaDB Cluster，一個是著名的MySQL服務和工具提供商Percona實現的Percona Xtradb Cluster，簡稱爲PXC。

從2016年開始，我參與了「移動雲」的MySQL數據庫運維管理工做。「移動雲」是一個不斷髮展壯大的雲服務供應商，訂單和用戶數據很是重要，隨着「移動雲」在網用戶數量的不斷增加，對數據庫的高可用性和數據一致性提出了更高的要求。通過長期研究，不斷地試錯，終於在Galera的基礎上，實現了一套本身的MySQL運維方案，截止到如今，已經有至關數量的線上集羣運行着通過標準化改造的PXC，在這個過程當中，咱們也積累了不少Galera的技術經驗，但願這些經驗也能幫助其餘Galera使用者解決疑難或規避問題。

PXC

Percona XtraDB Cluster是一個徹底開源的MySQL的高可用性解決方案。它將Percona Server和Percona XtraBackup與Galera庫集成，以實現同步多主複製。集羣由節點組成，其中每一個節點包含同一組數據同步的跨節點。推薦的配置是至少有3個節點。每一個節點都是常規的MySQL服務器實例（例如Percona Server）。能夠將現有的MySQL服務器實例轉換爲節點，並使用此節點做爲基礎來運行集羣。還能夠從集羣中分離任何節點，並將其用做常規的MySQL服務器實例。

集羣爲多主的模式，三個節點之間徹底是對等的，均可以做爲主節點，用戶可使用結構化查詢語言（SQL）對數據進行修改和查詢。該系統採用share nothing的架構，每一個節點均可以提供讀寫服務。任何節點的修改都會自動同步到全部節點，當有客戶端在某個節點寫入數據時，集羣會將新數據自動同步到其它節點，具備嚴格的數據一致性。

High Availability

集羣節點間經過同步複製進行數據同步，經過心跳實現異常節點的檢測和剔除。配合上層的負載均衡，能夠實現集羣的高可用，單個節點宕機不會影響服務。在具備3個節點的基本設置中，將任何節點關閉，Percona XtraDB Cluster仍能夠繼續工做。在任什麼時候間點，能夠關閉任何節點以執行維護或更改配置。即便在計劃外狀況（如節點崩潰或它網絡變得不可用），羣集會繼續工做，可在工做節點上運行查詢。

若是在節點關閉時對數據進行了更改，則節點在加入時可使用兩個選項加入集羣：

一、State Snapshot Transfer（SST）是將全部數據從一個節點複製到另外一個節點的過程。當新節點加入羣集並從現有節點接收全部數據時，一般使用SST。Percona XtraDB羣集中有三種SST方法：

mysqldump
rsync
xtrabackup

mysqldump和rsync的缺點是，你的集羣在數據存在時變成READ-ONLY 複製（SST應用FLUSH TABLES WITH READ LOCK命令）。

SST使用XtraBackup不須要READ LOCK命令整個同步過程當中，只要同步.FRM文件（同樣按期備份）。

二、Incremental State Transfer（IST）是指僅將增量更改從一個節點複製到另外一個節點。即便在羣集沒有鎖定爲只讀狀態，SST在正常操做服務時可能會侵入和干擾。IST能夠避免這樣。若是1個節點在很短的時間出現故障，它只能獲取發生在它失效時發生的那些更改。IST是在節點上使用高速緩存機制來實現的。每一個節點包含一個緩存，環形緩衝區（大小可配置）最後N個更改，而且節點間可以傳輸該高速緩存的一部分。顯然，只有當轉移所需的變化量小於N時IST才能完成。若是它超過N則加入節點必須執行SST。

可使用如下命令監視節點的當前狀態：

SHOW STATUS LIKE 'wsrep_local_state_comment';

當節點處於Synced（6）狀態時，它是集羣的一部分並準備處理流量。

Multi-Master Replication

多主複製意味着能夠寫入任何節點並確保寫入對集羣中全部節點都是一致的。這與常規MySQL複製不一樣，在常規MySQL複製中，您必須將寫入應用於master以確保它被同步。

PXC同步複製原理

事務在本地節點執行時採起樂觀策略，成功廣播到全部節點後再作衝突檢測；
檢測出衝突是，本地事務優先被回滾；
每一個節點獨立、異步執行隊列中的write set；
事務在本地節點執行成功返回客戶端後，其餘節點保證該事務必定會被執行，所以有可能存在延時，即虛擬同步。

PXC的複製架構圖（摘自官方文檔）

對於多主複製，任何寫入都在全部節點上提交或根本不提交。全部查詢都在節點上本地執行，而且僅在COMMIT上有特殊處理。當COMMIT查詢發出時，事務必須經過全部節點上的認證。若是它沒有經過，你會收到ERROR做爲響應。經過以後，事務在本地節點上應用。COMMIT的響應時間包括如下內容：

網絡往返時間；
認證時間；
本地申請。

注意：在遠程節點上應用事務不會影響COMMIT的響應時間。

這種架構有兩個重要的後果：

能夠並行使用幾個應用程序。這實現了真正的並行複製。使用 wsrep_slave_threads 變量配置的線程從機能夠有多個並行。
slave可能有一個小的時間段不一樣步。這是由於master能夠申請事件比slave更快。若是你從slave讀取，能夠讀取還沒有更改的數據。但能夠經過設置 wsrep_causal_reads = ON 變量來更改。在這種狀況下，在slave上讀取將等待，直到事件被應用（會明顯增長讀取的響應時間）。Slave和Master之間的差距是這種複製被稱爲虛擬同步的緣由，而不是真正的同步複製。

因此若是運行寫事務到兩個不一樣的節點，集羣將使用樂觀鎖。事務在個別查詢期間不會檢查可能的鎖衝突，而是在COMMIT階段，可能會收到ERROR響應。

Flow Control

前面瞭解了PXC是虛擬同步，事務在本地節點提交成功時，其餘節點保證執行該事務。在提交事務時，本地節點把事務複製到全部節點，以後各個節點獨立、異步地進行certification test、事務插入待執行隊列、執行事務。

然而因爲不一樣節點以前執行事務的速度不同，長時間運行後，慢節點的待執行隊列可能會越積越長，最終致使事務丟失。PXC繼承了Galera的flow control機制，做用是協調各個節點，保證全部節點執行事務的速度大於隊列增加的速度。實現原理是，集羣中同時只有一個節點能夠廣播消息，每一個節點都會得到廣播消息的機會，當慢節點的執行隊列超過必定長度後，它會廣播一個FC_PAUSE消息，其餘節點收到消息後會暫緩廣播消息，知道該慢節點的執行隊列長度減小到必定程度後，集羣數據同步又開始恢復。

部署架構案例

PXC部署架構分本地存儲和網絡存儲兩種狀況。其中，採用本地存儲的架構，其架構圖以下圖：

採用網絡存儲的架構，其架構圖以下：

介紹完PXC的原理和架構，下面看一下具體的平常運維工做。

數據庫巡檢

數據庫巡檢的內容一般涵蓋主機硬件、操做系統和MySQL巡檢項。其中，主機/os巡檢主要包括：主機的硬件配置、CPU/內存/磁盤使用率以及磁盤的I/O使用狀況；MySQL巡檢項包括：數據庫配置、用戶權限、大表數據量、業務表主鍵和自增加狀況、數據庫的併發性、當前和歷史鏈接狀況統計、備份執行狀況以及日誌記錄和慢SQL的分析優化等。

一、查看MySQL服務器配置信息及運行情況

經過show variables來查看mysql服務器配置信息，例如show variables like '%slow%'；用於查看慢查詢，show variables like 'max_connections';；用於查看最大鏈接數。

經過ps -ef | grep mysql查看mysql進程運行情況。

二、經過show status統計各類SQL的執行頻率

經過show status能夠查看服務器狀態信息。show status能夠根據須要顯示session 級別的統計結果和global級別的統計結果。

1）如下幾個參數對Myisam和Innodb存儲引擎都計數：

Com_select 執行select 操做的次數，一次查詢只累加1；
Com_insert 執行insert 操做的次數，對於批量插入的insert 操做，只累加一次；
Com_update 執行update 操做的次數；
Com_delete 執行delete 操做的次數。

2）如下幾個參數是針對Innodb存儲引擎計數的，累加的算法也略有不一樣：

Innodb_rows_read 執行select 查詢返回的行數；
Innodb_rows_inserted 執行insert 操做插入的行數；
Innodb_rows_updated 執行update 操做更新的行數；
Innodb_rows_deleted 執行delete 操做刪除的行數。

經過以上幾個參數，能夠很容易的瞭解當前數據庫的應用是以插入更新爲主仍是以查詢操做爲主，以及各類類型的SQL大體的執行比例是多少。對於更新操做的計數，是對執行次數的計數，不論提交仍是回滾都會累加。

對於事務型的應用，經過Com_commit和Com_rollback能夠了解事務提交和回滾的狀況，對於回滾操做很是頻繁的數據庫，可能意味着應用編寫存在問題。

3）如下幾個參數便於咱們瞭解數據庫的基本狀況：

Connections 試圖鏈接Mysql 服務器的次數；
Uptime 服務器工做時間；
Slow_queries 慢查詢的次數。

三、經過show status判斷系統瓶頸

1）QPS(每秒Query量)

QPS = Questions(or Queries) / seconds

mysql > show global status like 'Question%';

2）TPS(每秒事務量)

TPS = (Com_commit + Com_rollback) / seconds

mysql > show global status like 'Com_commit';

mysql > show global status like 'Com_rollback';

3）key Buffer 命中率

mysql>show global status like 'key%';

key_buffer_read_hits = (1-key_reads / key_read_requests) * 100%

key_buffer_write_hits = (1-key_writes / key_write_requests) * 100%

4）InnoDB Buffer命中率

mysql> show status like 'innodb_buffer_pool_read%';

innodb_buffer_read_hits = (1 - innodb_buffer_pool_reads /

innodb_buffer_pool_read_requests) * 100%

5）Query Cache命中率

mysql> show status like 'Qcache%';

Query_cache_hits = (Qcahce_hits / (Qcache_hits + Qcache_inserts )) * 100%;

6）Table Cache狀態量

mysql> show global status like 'open%';

比較open_tables與opend_tables值。

7）Thread Cache 命中率

mysql> show global status like 'Thread%';

mysql> show global status like 'Connections';

Thread_cache_hits = (1 - Threads_created / connections ) * 100%

建立用來處理鏈接的線程數。若是 Threads_created 較大，你可能要增長 thread_cache_size 值。緩存訪問率的計算方法 Threads_created/Connections。

8）鎖定狀態

mysql> show global status like '%lock%';

Table_locks_waited/Table_locks_immediate 若是這個比值比較大的話，說明表鎖形成的阻塞比較嚴重。

Innodb_row_lock_waits：innodb行鎖，太大多是間隙鎖形成的。

Table_locks_waited：不能當即得到的表的鎖的次數。若是該值較高而且有性能問題，應首先優化查詢，而後拆分表或使用複製。

9）Tmp Table 情況(臨時表情況)

mysql >show status like 'Created_tmp%';

Created_tmp_disk_tables/Created_tmp_tables比值最好不要超過10%，若是Created_tmp_tables值比較大，多是排序子句過多或者是鏈接子句不夠優化。

10）Binlog Cache 使用情況

mysql > show status like 'Binlog_cache%';

若是Binlog_cache_disk_use值不爲0 ，可能須要調大 binlog_cache_size大小。

11）Innodb_log_waits

mysql > show status like 'innodb_log_waits';

Innodb_log_waits值不等於0的話，代表 innodb log buffer 由於空間不足而等待。

12）鏈接數大小——max_connections

mysql> show variables like 'max_connections';

+-----------------------+-------+

| Variable_name | Value |

+----------------------+--------+

| max_connections | 500 |

+---------------------+--------+

mysql> show global status like 'max_used_connections';

+------------------------------+--------+

| Variable_name | Value |

+------------------------------+--------+

| Max_used_connections | 498 |

+-----------------------------+--------+

設置的最大鏈接數是500，而響應的鏈接數是498 。

max_used_connections / max_connections * 100% = 99.6% （理想值 ≈ 85%）

13）Handler_read_rnd

mysql> show status like 'Handler_read_rnd';

若是 Handler_read_rnd 太大，則你寫的 SQL 語句裏不少查詢都是要掃描整個表，而沒有發揮鍵的做用。

14）Key_reads

mysql> show status like 'key_read%';

+--------------------------+---------+

| Variable_name | Value |

+--------------------------+---------+

| Key_read_requests | 1190 |

| Key_reads | 2 |

+--------------------------+---------+

若是 Key_reads 太大，則應該把 my.cnf 中 key_buffer_size 變大，能夠用 Key_reads/Key_read_requests計算出 cache 失敗率。

15）Handler_read_rnd

mysql> show status like 'Handler_read_rnd';

根據固定位置讀一行的請求數。若是正執行大量查詢並須要對結果進行排序該值較高。可能使用了大量須要MySQL 掃描整個表的查詢或鏈接沒有正確使用鍵。

16）Handler_read_rnd_next

mysql>show status like 'Handler_read_rnd_next';

在數據文件中讀下一行的請求數。若是你正進行大量的表掃描，該值較高。一般說明你的表索引不正確或寫入的查詢沒有利用索引。

17）Select_full_join

mysql>show status like 'Select_full_join';

沒有使用索引的聯接的數量。若是該值不爲 0, 你應仔細檢查表的索引。

18）Select_range_check

mysql>show status like 'Select_range_check';

在每一行數據後對鍵值進行檢查的不帶鍵值的聯接的數量。若是不爲 0 ，你應仔細檢查表的索引。

19）Sort_merge_passes

mysql>show status like 'Sort_merge_passes';

排序算法已經執行的合併的數量。若是這個變量值較大，應考慮增長 sort_buffer_size 系統變量的值。

20）Handler_read_first

mysql>show status like 'Handler_read_first';

索引中第一條被讀的次數。若是較高，它代表服務器正執行大量全索引掃描。例如， SELECT col1 FROM foo ，假定col1 有索引。

21）Handler_read_key

mysql>show status like 'Handler_read_key';

根據鍵讀一行的請求數。若是較高，說明查詢和表的索引正確。

22）Handler_read_next

mysql>show status like 'Handler_read_next';

按照鍵順序讀下一行的請求數。若是你用範圍約束或若是執行索引掃描來查詢索引列，該值增長。

23) Handler_read_prev

mysql>show status like 'Handler_read_prev';

按照鍵順序讀前一行的請求數。該讀方法主要用於優化 ORDER BY ... DESC 。

24）Handler_read_rnd

mysql>show status like 'Handler_read_rnd';

根據固定位置讀一行的請求數。若是你正執行大量查詢並須要對結果進行排序該值較高。你可能使用了大量須要MySQL 掃描整個表的查詢或你的鏈接沒有正確使用鍵。

四、打開相應的監控信息

1）error log

在配置文件my.cnf中進行配置，在運行過程當中不能改變。

2）打開慢查詢

set global slow_query_log='ON';

3）設置慢查詢的時間閾值

set global long_query_time = 0.1;

4）未使用索引的sql語句打開

set global log_queries_not_using_indexes='ON

早期咱們經過執行自動化腳原本輸出巡檢報告，巡檢報告內容須要人工去檢查和確認，執行巡檢腳本主要包括如下步驟：

首先是，在本地下載python3.5並安裝，打開後進入python解析器；
經過pip方式安裝python依賴包；
由於腳本中須要獲取graphid，要登陸zabbix管理網站去獲取；
而後登陸堡壘機，配置端口轉發策略；
登陸每一套數據庫，建立數據庫巡檢帳號；
最後在本地執行巡檢腳本，並最終合成word巡檢報告。

雖然比手工執行巡檢，要簡化不少，而且能夠按資源池批量執行巡檢，但總的來講過程仍是略繁瑣。目前咱們在作的是採用平臺化的方式，取代傳統的腳本和工具巡檢。經過搭建數據庫管理平臺，實現巡檢管理，其中一鍵巡檢功能用於數據庫的例行巡檢。可選擇多臺數據庫批量執行巡檢。巡檢結果能在web頁面上查看。並針對每一個數據庫實例會生成一份標準格式的巡檢報告，報告能夠從web頁面直接下載。

另外，平臺也提供了快速巡檢的功能，用於對一些常規項巡檢進行快速排查，常規巡檢項主要是DBA根據以往故障處理的經驗，總結下來的一些經常使用的排查項目，例如：processlist當前鏈接狀況覈查，而且能夠保留快照，數據庫阻塞的狀況覈查、流控的狀況檢查、鎖爭用的核查以及一些臨時表和詢緩存等狀況的檢查，下圖中的例子是對當前鏈接狀況的排查，能夠看到什麼用戶正鏈接數據庫在執行哪些操做。

另外，做爲對常規巡檢項的補充，也提供了自定義巡檢項的功能。能夠執行一些臨時的查詢語句，而且結合了語義審覈和轉譯的功能，可以保證sql語句的正確使用，查詢結果能夠從web頁面上導出。下圖中的例子是臨時對數據庫帳號的進行查詢，並導出結果。

複製引擎監控管理

一、打開復制引擎的調試信息-wsrep_debug

在運行過程當中，能夠經過set global wsrep_debug = 'ON'；來動態地打開wsrep的調試信息（調試信息會輸入到錯誤日誌中），能夠幫助複製引擎定位問題。

二、Galera集羣監控

1）監控集羣的一致性

mysql>show status like 'wsrep_cluster_state_uuid';

經過檢查變量wsrep_cluster_state_uuid的值，確認此節點是否屬於正確的集羣。該變量的值在集羣的各個節點中必須相同，若是某個節點出現不一樣的值，說明此節點沒有鏈接到集羣中。

mysql>show status like 'wsrep_cluster_conf_id';

經過檢查變量wsrep_cluster_conf_id的值，用於查看集羣發生變化的總數，同時確認此節點是否屬於主集羣。該變量的值在集羣的各個節點中必須相同，若是某個節點出現不一樣的值，說明此節點脫離集羣了，須要檢查網絡鏈接等將其恢復到一致的狀態。

mysql>show status like 'wsrep_cluster_size';

經過檢查變量wsrep_cluster_size的值，查看集羣節點的總數。

mysql> show status like 'wsrep_cluster_status';

經過檢查變量wsrep_cluster_status的值，查看節點的狀態是否爲Primary，若不爲Primary，表示集羣部分節點不可用，甚至多是集羣出現了腦裂。

若是全部節點的狀態都不爲Primary，就須要重置仲裁，若是不能重置仲裁，就須要手動重啓。

第一步，關閉全部節點

第二步，重啓各個節點，重啓過程當中能夠參考wsrep_last_committed的值肯定主節點。

注：手動重啓的缺點是會形成緩存丟失，從而不能作IST。

2）監控節點狀態

mysql> show status like 'wsrep_ready';

經過檢查變量wsrep_ready的值，查看該節點的狀態是否能夠正常使用SQL語句。若是爲ON，表示正常，若爲OFF，需進一步檢查wsrep_connected的值。

mysql> show status like 'wsrep_connected';

若是此變量的值爲OFF，說明該節點尚未加入到任何一個集羣組件中，這極可能是由於配置文件問題，例如wsrep_cluster_address或者wsrep_cluster_name值設置錯誤，也能夠經過查看錯誤日誌進一步定位緣由。

若是節點鏈接沒有問題，但wsrep_ready的值還爲OFF，檢查wsrep_local_state_comment的值。

mysql> show status like 'wsrep_local_state_comment';

當節點的狀態爲Primary時，wsrep_local_state_comment的值通常爲Joining, Waiting for SST, Joined, Synced或者Donor，若是wsrep_ready爲OFF，而且wsrep_local_state_comment的值爲Joining, Waiting for SST, Joined其中一個，說明此節點正在執行同步。

當節點的狀態不爲Primary時，wsrep_local_state_comment的值應該爲Initialized。任何其餘狀態都是短暫的或臨時的。

3）檢測複製的健康狀態

mysql> show status like 'wsrep_flow_control_paused';

經過檢查變量wsrep_flow_control_paused的值，能夠確認有多少slave延遲在拖慢整個集羣的，從而查看複製的健康狀態。這個值越接近0.0越好，優化的方法主要經過增長配置文件中wsrep_slave_threads的值，或者將複製很慢的節點剔除出集羣。wsrep_slave_threads取值能夠參考wsrep_cert_deps_distance，wsrep_cert_deps_distance表示併發事務處理數的均值，wsrep_slave_threads的值不該該比wsrep_cert_deps_distance高不少。

4）檢測網絡慢的問題

mysql> show status like 'wsrep_local_send_queue_avg';

經過檢查變量wsrep_local_send_queue_avg的值，能夠檢測網絡狀態。若是此變量的值偏高，說明網絡鏈接多是瓶頸。形成此狀況的緣由可能出如今物理層或操做系統層的配置上。

5）集羣監控通知擴展

經過wsrep_notify_cmd參數調用命令腳本的二次擴展。

wsrep狀態監控

mysql> show status like '%wsrep%';

+------------------------------------------+-------------------------------------------------------+

| Variable_name | Value |

+------------------------------------------+-------------------------------------------------------+

| wsrep_local_state_uuid | e8149a5c-636a-11e5-8b4b-67b16bb666a4 |

| wsrep_protocol_version | 7 |

| wsrep_last_committed | 526498 |

| wsrep_replicated | 526498 |

| wsrep_replicated_bytes | 238196578 |

| wsrep_repl_keys | 1926403 |

| wsrep_repl_keys_bytes | 27520685 |

| wsrep_repl_data_bytes | 176980021 |

| wsrep_repl_other_bytes | 0 |

| wsrep_received | 7970 |

| wsrep_received_bytes | 64791 |

| wsrep_local_commits | 526357 |

| wsrep_local_cert_failures | 0 |

| wsrep_local_replays | 0 |

| wsrep_local_send_queue | 0 |

| wsrep_local_send_queue_max | 2 |

| wsrep_local_send_queue_min | 0 |

| wsrep_local_send_queue_avg | 0.000041 |

| wsrep_local_recv_queue | 0 |

| wsrep_local_recv_queue_max | 4 |

| wsrep_local_recv_queue_min | 0 |

| wsrep_local_recv_queue_avg | 0.034504 |

| wsrep_local_cached_downto | 1 |

| wsrep_flow_control_paused_ns | 22690449177 |

| wsrep_flow_control_paused | 0.000005 |

| wsrep_flow_control_sent | 0 |

| wsrep_flow_control_recv | 371 |

| wsrep_cert_deps_distance | 74.734609 |

| wsrep_apply_oooe | 0.000000 |

| wsrep_apply_oool | 0.000000 |

| wsrep_apply_window | 1.000000 |

| wsrep_commit_oooe | 0.000000 |

| wsrep_commit_oool | 0.000000 |

| wsrep_commit_window | 1.000000 |

| wsrep_local_state | 4 |

| wsrep_local_state_comment | Synced |

| wsrep_cert_index_size | 43 |

| wsrep_cert_bucket_count | 126282 |

| wsrep_gcache_pool_size | 261431296 |

| wsrep_causal_reads | 0 |

| wsrep_cert_interval | 0.000002 |

| wsrep_incoming_addresses | 10.130.7.5:3306,,10.130.7.4:3306 |

| wsrep_evs_delayed | |

| wsrep_evs_evict_list | |

| wsrep_evs_repl_latency | 0/0/0/0/0 |

| wsrep_evs_state | OPERATIONAL |

| wsrep_gcomm_uuid | e813b31f-636a-11e5-90c7-0f6d378e1dfb |

| wsrep_cluster_conf_id | 5 |

| wsrep_cluster_size | 3 |

| wsrep_cluster_state_uuid | e8149a5c-636a-11e5-8b4b-67b16bb666a4 |

| wsrep_cluster_status | Primary |

| wsrep_connected | ON |

| wsrep_local_bf_aborts | 0 |

| wsrep_local_index | 2 |

| wsrep_provider_name | Galera |

| wsrep_provider_vendor | Codership Oy <info@codership.com> |

| wsrep_provider_version | 3.11(rXXXX) |

| wsrep_ready | ON |

+----------------------------------------+---------------------------------------------------+

58 rows in set (0.12 sec)

wsrep相關參數含義介紹：

wsrep_local_state_uuid：存儲於該節點的UUID狀態

wsrep_protocol_version：wsrep協議使用的版本

wsrep_last_committed：最後提交事務的序列號

wsrep_replicated：發送到其餘節點的writesets總數

wsrep_replicated_bytes：發送到其餘節點的writesets總字節數

wsrep_repl_keys：複製keys總數

wsrep_repl_keys_bytes：複製keys總字節數

wsrep_repl_data_bytes：複製數據的總字節數

wsrep_repl_other_bytes：其餘複製的總字節數

wsrep_received：從其餘節點接收的writesets總數

wsrep_received_bytes：從其餘節點接收的writesets總字節數

wsrep_local_commits：該節點提交的writesets總數

wsrep_local_cert_failures：認證測試中失敗的writesets總數

wsrep_local_replays：因非對稱鎖粒度回放的事務數

wsrep_local_send_queue：當前發送隊列的長度，表示等待被髮送的writesets數

wsrep_local_send_queue_avg：網絡瓶頸的預兆。若是這個值比較高的話，可能存在網絡瓶

wsrep_local_recv_queue：當前接收隊列的長度，表示等待被使用的writesets數

wsrep_local_recv_queue_avg：表示slave事務隊列的平均長度，slave瓶頸的預兆

wsrep_local_cached_downto：gcache的最小序列號，這個變量能夠用來判斷是用IST，仍是SST。若是此值爲0，表示gcache中沒有writesets

wsrep_flow_control_paused_ns：表示複製中止了多長時間，以納秒爲單位

wsrep_flow_control_paused：表示複製中止了多長時間。即代表集羣由於Slave延遲而慢的程度，值爲0~1，越靠近0越好，值爲1表示複製徹底中止。可優化wsrep_slave_threads的值來改善

wsrep_flow_control_sent：表示該節點已經中止複製了多少次

wsrep_flow_control_recv：表示該節點已經中止複製了多少次

wsrep_cert_deps_distance：有多少事務能夠並行應用處理。wsrep_slave_threads設置的值不該該高出該值太多

wsrep_apply_oooe：併發執行效率，writesets應用於out-of-order的頻率

wsrep_apply_oool：大序列值的writeset比小序列值的writeset多出的執行頻率

wsrep_apply_window：同時使用的最高序列值和最小序列值間的平均差值

wsrep_commit_oooe：事務脫離隊列的頻率

wsrep_commit_window：同時提交的最大序列值和最小序列值間的平均差值

wsrep_local_state：galera狀態值

1 - Joining (requesting/receiving State Transfer) –表示此節點正在加入集羣

2 - Donor/Desynced –表示正在加入的節點是donor

3 - Joined –表示節點已經加入集羣r

4 - Synced –表示節點已經和集羣同步

wsrep_local_state_comment：galera狀態，若是wsrep_connected爲On，但wsrep_ready爲OFF，則能夠從該項查看緣由

wsrep_cert_index_size：certification索引的entries數量

wsrep_cert_bucket_count：哈希表中certification索引的cells數

wsrep_gcache_pool_size：page pool或者爲gcache動態分配的字節數

wsrep_causal_reads：writesets處理數

wsrep_incoming_addresses：以逗號分隔顯示集羣中的節點地址

wsrep_evs_repl_latency：提供集羣節點間通訊複製延遲信息

wsrep_evs_delayed：被剔除出集羣的UUID

wsrep_evs_evict_list：有延遲的節點列表

wsrep_evs_state：EVS協議狀態

wsrep_gcomm_uuid：galera的view_id，不一樣於集羣的uuid，在gvwstate.dat能夠查看到

wsrep_cluster_conf_id：集羣成員發生變化的數目，正常狀況下全部節點上該值是同樣的。若是值不一樣，說明該節點被臨時"分區"了。當節點之間網絡鏈接恢復的時候應該會恢復同樣的值

wsrep_cluster_size：集羣中的節點數目，若是這個值跟預期的節點數一致，則全部的集羣節點已經鏈接

wsrep_cluster_state_uuid：集羣的UUID值，在集羣全部節點的值應該是相同的，有不一樣值的節點，說明其沒有鏈接入集羣

wsrep_cluster_status：集羣節點的狀態。若是不爲"Primary"，說明出現"分區"或是"split-brain"情況，可能的取值爲:Primary、Non-Primary、Disconnected

wsrep_connected：節點是否鏈接到集羣，若是該值爲Off，且wsrep_ready的值也爲Off，則說明該節點沒有鏈接到集羣。(多是wsrep_cluster_address或wsrep_cluster_name等配置錯形成的。具體錯誤須要查看錯誤日誌)

wsrep_local_bf_aborts：被其餘節點上的事務終止的正在執行的本地事務數

wsrep_local_index：集羣節點索引

wsrep_provider_name：wsrep程序提供者

wsrep_provider_vendor：wsrep供應商

wsrep_provider_version：wsrep程序提供者的版本

wsrep_ready：節點是否能夠提供查詢。該值爲ON，則說明能夠接受SQL負載。若是爲Off，則須要檢查wsrep_connected

▲ 框內下拉可查看完整內容

PXC備份管理

對於咱們來講，數據庫的備份和恢復是很平常的工做。由於平時不免會遇到服務器宕機、磁盤損壞等狀況，在這種狀況下，要保證數據不丟失或者最小程度的丟失，平時進行有效的備份就顯得很是重要了。

所以對於DBA來講，備份工具的使用、備份策略的選擇以及備份系統的完善都是須要特別關注的，另外，像備份文件校驗一般是比較容易忽視的問題，出現故障時發現備份文件不可用，會形成很嚴重損失。

咱們平時經常使用的備份工具是mysqldump、Percona Xtrabackup，分別用於邏輯備份和物理備份，其實大多數DBA的備份/恢復體系都是圍繞這兩個工具展開的。

早期咱們經過在數據庫本地，按期執行腳本的方式進行備份，策略是：每週日凌晨2點執行一次全量備份，週一到週六天天凌晨2點執行增量備份，在本地存儲空間充足的狀況下，要求至少要求保留1個月的備份數據，備份恢復測試是經過在備份恢復測試機上面執行‘測試腳本’，每週六分時段從各個數據庫拉取備份文件到本機進行恢復測試，並經過日誌記錄恢復操做是否成功。

那當面對成百上千個MySQL實例的維護，以上備份恢復方式會有哪些問題呢？咱們具體來看一下。

一、首先是對本地存儲空間需求較大，而且佔用服務器系統總線，內存，CPU，磁盤IO資源，使得備份對線上業務有必定的影響。

在現網環境中，因爲本地磁盤空間有限，一般本地僅保留一個月左右的備份數據，對於更早的數據如無特殊需求，到後期會自動刪除，對於較重要的數據要保留更久要經過遠程備份實現，不過在遠程備份時，備份傳輸引起的網卡流量會對線上業務形成影響，須要考慮到網卡的能力。這時能夠考慮使用雙網卡，一塊用於備份，一塊用來提供線上服務。若是沒有這個條件，要經過在備份時限速來達到目的。

二、其次是，集中化管理缺失，備份節點較多，備份方式多樣化，備份完成狀況、佔用空間大小、完成時間以及校驗結果等內容的記錄和呈現也不夠直觀，缺乏圖形化界面。突發故障或變動前的臨時備份依然靠手工執行，存在效率低和安全性差的問題。

三、集羣備份節點選擇問題。備份或多或少對線上業務都有影響，建議備份任務在slave或只讀節點上執行，那麼當集羣發生主備切換，若是備份節點沒有動態進行切換，致使在寫庫上進行備份，使線上業務受備份操做影響。

爲了解決上述問題，咱們仍是採用平臺化的方式，經過開發來實現集中化管理，包括：備份執行與恢復管理、歷史備份查看以及備份策略修改和管理等功能。

另外想要提一下的是容災，容災是指在備份的基礎上創建一個異地的數據系統，這個系統是本地關鍵應用數據的一個實時複製。

在災難發生時，能夠支持自動和手工災備切換功能，保正業務的連續性。

PXC常見故障排查和處理方法

節點宕機

當集羣中出現讀寫服務節點宕機的狀況時，應該按以下所述步驟進行處理，以對外提供服務。

1）讀寫服務節點宕機

① 查看集羣各節點狀態：ps –ef | grep rdb

結果：讀寫節點(RW3)進程不存在，其餘節點服務正常

② 查看error log日誌，檢查宕機緣由

③ 重啓RW3

④ 啓動完成後，確認RW3狀態是否正常

2）某兩個讀寫服務節點宕機

① 查看集羣各節點狀態：ps –ef | grep rdb

結果：讀寫節點(RW二、RW3)進程不存在，RW1節點服務正常

② 查看error log日誌，檢查宕機緣由

③ 此時，RW1讀寫服務節點正常工做，重啓RW2和RW3

④ 啓動完成後，確認RW2和RW3狀態是否正常

3）讀寫服務節點都宕機

① 查看集羣各節點狀態：ps –ef | grep rdb

結果：讀寫節點（RW一、RW二、RW3）進程均不存在，此時集羣沒法提供正常服務

② 查看error log日誌，發現最後宕機的是RW3

③ 關閉集羣：kill -15 PID

④ 從新啓動最後宕掉的讀寫服務節點RW3

⑤ RW3狀態恢復正常後，根據實際負載狀況判斷是否繼續啓動RW2和RW1，預判若是可能作SST，因爲作donor的節點沒法提供服務，服務恢復時間比較長，能夠先不起後面的節點，暫時只讓RW3提供服務，閒時再啓動其餘節點，這種狀況下要注意限制數據庫的鏈接數。啓動RW2節點

⑥ 待數據同步結束，RW2狀態恢復正常後，啓動RW1節點

⑦ 檢查各個節點的狀態，是否能正常提供服務

節點無響應

當集羣中出現任一讀寫節點無響應時，應該按以下所述步驟進行處理，以對外提供服務。

1）負載高

主要查看如下幾項：CPU使用率，內存使用率，操做系統IO，網絡IO，網絡鏈接數等。對應的命令和工具爲：SystemTap，LatencyTOP，vmstat, sar, iostat, top, tcpdump等。經過觀察這些指標，咱們就能夠定位系統的性能問題。具體檢查順序可參看下述步驟：

① 先看CPU使用率，若是CPU使用率不高，但系統的Throughput和Latency上不去，這說明應用程序並無忙於計算，而是忙於別的一些事，好比IO。（另外，CPU的利用率還要看內核態的和用戶態的，內核態的上去了，整個系統的性能就下來了。而對於多核CPU來講，CPU 0 是至關關鍵的，若是CPU 0的負載高，那麼會影響其它核的性能，由於CPU各核間是須要有調度的，這靠CPU0完成）。

② 查看一下IO大不大，IO和CPU通常是反着來的，CPU利用率高則IO不大，IO大則CPU利用率就低。關於IO，咱們要看三個事，一個是磁盤文件IO，一個是驅動程序的IO（如：網卡），一個是內存換頁率。這三個事都會影響系統性能。

③ 查看一下網絡帶寬使用狀況，在Linux下，你可使用iftop, iptraf, ntop, tcpdump這些命令來查看，或是用Wireshark來查看。

④若是CPU不高，IO不高，內存使用不高，網絡帶寬使用不高，可是系統的性能上不去。這說明你的程序有問題，好比，你的程序被阻塞了。多是由於等哪一個鎖，多是由於等某個資源，或者是在切換上下文。

經過了解操做系統的性能，咱們才知道性能的問題，好比：帶寬不夠，內存不夠，TCP緩衝區不夠等等，不少時候，不須要調整程序的，只須要調整一下硬件或操做系統的配置就能夠了。

注：OS經常使用查看命令

cpu – vmstat、top、sar

內存– ipcs、free

io – iostat、sar

網絡– tcpdump、netstat –i、sar

預防措施：

合理調整數據庫的參數；
應用上線前進行測試，優化後上線。防止應用大批量處理sql，insert、select等語句；
監控系統資源負荷狀況；
限制報表併發查詢數量，參照業務吞吐量。

處理方法：

① 排查執行時間較長的sql語句，步驟以下：

在各節點執行show full processlist；將執行時間較長的sql語句及執行該語句的線程ID(show full processlist顯示結果中的列Id值)記錄下來；

② 針對記錄下來的sql語句，與應用相關人員確認是否可以終止；

說明：對於發現執行時間較長且仍在執行的select語句，爲了下降風險，在必要狀況下能夠直接終止；對於涉及數據更新的語句，須要根據實際狀況進行相關處理（好比記錄下 SQL語句以便後續分析）；

③ 終止執行時間較長且已獲得終止確認的sql語句，kill QUERY ID或者KILL ID(執行sql語句的線程ID)；

④ 確認集羣是否正常響應。

2）鏈接滿

當鏈接數滿時，用戶鏈接不上數據庫，當前正在接受讀寫的節點達到最大鏈接值會沒法鏈接數據庫，按照如下方法處理：

根據歷史統計信息修改max_connections。

方法一：

① 第max_connections+1鏈接只能由擁有super privileges用戶登陸，當鏈接數滿時，擁有super_priv的用戶登錄數據庫修改max_ connections值：

set GLOBAL max_connections=XXXX;修改完成後實時生效，無需重啓數據庫。

② 進入配置文件my.cnf，設置max_connections值，該值與步驟一的值相同。

方法二：

進入配置文件my.cnf，設置max_connections值，並重啓該節點服務。

3）有鎖表狀況

預防措施：

① 監控鎖等待數量，暫設置10個報警；

② 避免業務忙時進行批量更新操做。

當出現有鎖表狀況而致使數據庫響應慢的狀況時，應該按以下所述步驟進行處理：

方法一：

① 獲取鎖表狀況的相關信息，步驟以下：

(a) 以root用戶登錄到各主節點機器上；
調用客戶端鏈接工具；
在各主節點的mysql提示符下執行use information_schema；
在各主節點的mysql提示符下執行以下sql語句；

select a.trx_id ,a.trx_query , b.lock_data

from innodb_trx a ,innodb_locks bwhere a.trx_id = b.lock_trx_id;

② 針對鎖信息查詢語句的查詢結果，與應用相關人員確認是否能夠kill

③ 若是應用確承認以kill，則kill對應的sql

方法二：

調整innodb_lock_wait_timeout值。

集羣分裂沒法提供服務

當集羣出現分裂的狀況時，應該按以下所述步驟進行處理，以對外提供服務。

1）集羣中有節點狀態是Primary

① 使用如下命令查看集羣狀態，查找狀態爲non-Primary的節點

SHOW STATUS where Variable_name="wsrep_cluster_status";

+------------------------------+----------+

| Variable_name | Value |

+-----------------------------+----------+

| wsrep_cluster_status |non- Primary |

+--------------------------+---------------+

② 重啓狀態爲non-Primary的節點

③ 檢查各個節點的狀態，是否能正常提供服務

2）集羣中全部節點狀態都不是Primary

① 使用如下命令查看集羣狀態，發現集羣已經整個分裂，狀態均爲non-Primary

SHOW STATUS where Variable_name="wsrep_cluster_status";

+-----------------------------+----------------+

| Variable_name | Value |

+-----------------------------+----------------+

| wsrep_cluster_status |non- Primary |

+-----------------------------+----------------+

② 從新執行選主。選主規則：以最後提交事務的數據庫節點選爲主，做爲啓動集羣的主節點。同時，主節點對應的seqno也是最大的，能夠經過如下命令查看

SHOW STATUS LIKE 'wsrep_last_committed';

+---------------------------+---------+

|Variable_name |Value |

+--------------------------+---------+

|wsrep_last_committed|409745|

③ 若是RW1是當前的主節點，則在RW1下執行下面的命令，從新引導RW1爲primary：

set global wsrep_provider_options ="pc.bootstrap=1";Kill -15 pid關閉其餘節點，關閉後能夠經過grastate.dat裏的uuid和seqno判斷是否會作SST，kill -15關閉的通常不會有SST，只有IST，能夠當即重啓其餘節點

④ 首先啓動RW2節點

⑤ 待數據同步結束，RW2狀態恢復正常後，啓動RW3節點

⑥ 檢查各個節點的狀態，是否能正常提供服務

其餘異常

1）集羣因斷電宕機

① ping 服務器端IP地址失敗

② 聯繫網絡管理員或系統管理員進行處理，重啓服務器

③ 重啓數據庫

經過查看各節點的日誌，假設最後關閉節點是RW1

從新啓動最後關閉的讀寫服務節點RW1

待數據同步結束，RW1狀態恢復正常後，啓動RW2節點

待數據同步結束，RW2狀態恢復正常後，啓動RW3節點

檢查各個節點的狀態，是否能正常提供服務

2）網絡交換機故障形成集羣對外鏈接中斷

① ping 服務器端IP地址失敗

② 查看/var/log/messages

③ 聯繫網絡管理員或系統管理員進行處理

3）網絡交換機故障形成集羣內部鏈接中斷

① ping 服務器端IP地址成功

② ping 集羣內部各節點IP失敗

③ 查看/var/log/messages

④ 聯繫網絡管理員或系統管理員進行處理

4）磁盤故障形成集羣沒法提供服務

① 使用smartctl檢測磁盤健康狀態

② 聯繫系統管理員更換磁盤

③ 重啓數據庫

案例1

去年9月8號，晚上11點左右，研發人員對數據庫進行操做時，執行了1個事務，向用戶註冊表添加數據，這是一條insert語句，可是忘了提交，而後又執行了另外一條sql，去修改同一張表的表結構，前面沒有提交的insert語句已對用戶註冊表添加了排他鎖，致使後續大量sql語句等待執行，引起數據庫阻塞，直到30min後第1個事務超時，數據庫阻塞才解除。

咱們當時在11：08收到zabbix告警，顯示數據庫活躍線程數已達到139，通常活躍線程數超過32就會開始積壓，這個跟CPU能處理的線程數有關，所以告警值設置爲32。初步排查緣由爲元數據索致使，11:07用戶開了一個insert語句沒有提交，致使元數據鎖。

元數據鎖產生的緣由，簡單來講就是修改表數據的同時，修改表結構。爲了不這種狀況，mysql innodb 在執行寫入操做時會對錶，添加排它鎖，修改表結構，要等待鎖釋放後才能執行。此次故障處理，沒有直接kill掉阻塞線程，由於按以往經驗，這種方式能夠解決阻塞，但也有必定機率會引發數據文件損壞，因此在阻塞事務即將超時的狀況下，並無作任何操做，而是等待事務超時後，數據庫自動恢復。

案例2

第二個例子是，去年11月1號，研發人員在數據庫執行查詢操做，由於使用排序產生臨時表，又由於instance表，跟關聯查詢語句中的任何表都沒有關聯關係，致使笛卡爾積，生成的臨時表文件過大最終將/目錄佔滿，從而引起故障。

案例3

第三個案例是因爲網絡設備故障引發的，存儲網卡閃斷致使數據庫宕機，在去年6月1日上午10:46，數據庫進程故障，有12臺數據庫同時宕機，一線接到客戶投訴‘華北節點控制檯沒法打開’，當時看了一下，因爲mysqld進程屬於非正常關閉，啓動以前要登陸集羣3個節點，查看啓動位置sequence number,找出具備最完整數據的節點，做爲集羣第一個節點優先啓動，而後再啓動另外兩個節點同步數據。

可是，在嘗試執行mysqld_safe命令查看啓動位置的時候失敗了，繼續排查，最後找到故障緣由：數據庫主機掛載塊存儲的目錄變成只讀狀態，從新掛載後命令能夠正常執行，而後將數據庫陸續啓動。

此次故障緣由，在後面回溯的時候發現是由於數據庫主機存儲網卡與上層網絡設備互聯信息過程當中發生了閃斷，致使存儲目錄變爲只讀狀態，最後引起故障