聚會時間公告: 因應COSCUP 2011, Kalug 8月份休會一次

五月 9, 2014

小惡魔AppleBOY
AppleBOY
is about »

tag cloud

» 免費下載 Percona MySQL eBooks

percona

玩 MySQL 的一定知道 Percona,這次 Percona MySQL 推出免費電子書,電子書內容是從 MySQLPerformanceBlog 裡面精心挑選文章收錄,文章內容也幾乎都是 MySQL 專家寫出來的,電子書內容包含了MySQL server, Percona Server, Percona XtraDB Cluster, MySQL performance, and MySQL troubleshooting,所有的電子書都是免費下載。

更多主題可以直接參考 MySQL eBooks

二月 9, 2014

小惡魔AppleBOY
AppleBOY
is about »

tag cloud

» Percona XtraDB Cluster 5.6 找合適 IST Donor

percona

Gcache 是用來紀錄 MySQL 最近所使用的 SQL Command,其本身是佔用記憶體空間,大小可以由 wsrep_provider_options 定義,如果有任何 MySQL Node 重新啟動,那麼可以經由 Live Node 內的 Gcache 將尚未同步的資料補上,同步資料的方式分為兩種一種為 IST(Incremental State Transfer) 另一種為 SST(State Snapshot Transfer),但是同步資料時,管理者無法決定同步方式。先來看看 Gcache 一些特性

  • node 重新啟動,Gcache 資料會全部消失
  • Gcache 大小為固定,如果超過大小,則回刪除最早資料
  • 選擇 Donor node 會直接忽略 Gcache 狀態
  • Node 重新啟動,需要同步的資料並非在指定 Node Gcahe 內,則會啟動 SST 同步
  • 到目前版本為止,沒有任何方式可以知道 Gcache 狀態

根據以上特性可以知道,當 Node 重新啟動,很容易就執行 SST 模式,舉例子來說,當有 Node crashed 超過一個晚上,你要如何知道其他 Node 內的 Gcache 資料大於需要同步的資料量?或者是當 Cluster 內只有兩台機器,那重新啟動任何一台 Node 都會是跑 SST 同步。

PXC 5.6.15 RC1

去年 Percona XtraDB Cluster 推出 PXC 5.6.15 版本,此版本可以知道 Gcache 狀態,透過 wsrep_local_cached_downto 變數可以知道目前 Gcache 狀態,現在管理者就可以透過此參數來決定特定的 Node 進行 IST 同步,而不是 SST 同步。底下透過三台機器做實驗,並依照下面步驟。

  1. 停用 Node 2
  2. 停用 Node 3
  3. 啟用 Node 2

看到第3步驟,我們可以知道因為重新啟動的速度很快,所以 Node 2 肯定透過 IST 同步資料,最後從新啟動 Node 3 之前,我們可以透過 mysql 指令來看 wsrep_local_cached_downto 資料

[root@node1 ~]# mysql -e "show global status like 'wsrep_local_cached_downto';"
+---------------------------+--------+
| Variable_name             | Value  |
+---------------------------+--------+
| wsrep_local_cached_downto | 889703 |
+---------------------------+--------+
[root@node2 mysql]# mysql -e "show global status like 'wsrep_local_cached_downto';"
+---------------------------+---------+
| Variable_name             | Value   |
+---------------------------+---------+
| wsrep_local_cached_downto | 1050151 |
+---------------------------+---------+

可以看到 Node 2 的值大於 Node 1,這代表 Node 2 有些資料尚未跟 Node 1 同步上,此時看看 Node 3 資料,也可以透過 /var/lib/mysql/grastate.dat 檔案來知道

[root@node3 ~]# cat /var/lib/mysql/grastate.dat
# GALERA saved state
version: 2.1
uuid:    7206c8e4-7705-11e3-b175-922feecc92a0
seqno:   1039191
cert_index:

這時候會發現,node 3 資料比 node 2 資料還新,node 3 重新啟動後,如果是跟 node 2 同步的話,那就是會走 SST 機制,如果是跟 Node 1 則是走 IST 機制,當然走 IST 才是我們想要的結果,但是在 PXC 5.6.15 版本之前並非有參數可以讓系統管理者決定。所以這時候可以透過指定方式來跟 Node 1 同步

$ service mysql start --wsrep_sst_donor=node1

目前至少可以透過 wsrep_local_cached_downto 來知道 Gcache 狀態。本篇數據來自於 Finding a good IST donor in Percona XtraDB Cluster 5.6

一月 23, 2014

小惡魔AppleBOY
AppleBOY
is about »

tag cloud

» MySQL 5.6 UUID 複製資料到 Slave Server

mysql_logo

MySQL Performance Blog 看到這篇 Beware of MySQL 5.6 server UUID when cloning slaves,裡面提到如果是要複製資料到 Slave 機器,大部分的使用者肯定是將 /var/lib/mysql 目錄整個 copy 到 Slave 機器上。如果是 MySQL 5.6 Server 目錄內會有 auto.cnf 設定檔,這是 MySQL 5.6 新的功能叫做 server_uuid,在啟動 MySQL 後,就會自動建立 auto.cnf 檔案,此檔案就像是 my.cnfmy.ini 設定檔一樣,只是內容只有支援 [auto] 並且只有支援 server_uuid 這 key 值,例如

[auto]
server_uuid=8a94f357-aab4-11df-86ab-c80aa9429562

注意的是此檔案是系統自動建立,請勿自行修改內容。如果將 /var/lib/mysql 複製到其他機器,就會出現 server uuid 衝突,所以請務必小心,複製到新的伺服器後,請把 auto.cnf 移除,讓系統重新建立新的 uuid,如果是用 Percona XtraBackup 就不會出現此問題。

support:

biggo.com.tw

biggo.sg

A Django site.