前面介紹了基于mycat中間的MySQL架構(gòu)，從mysql數(shù)據(jù)庫、mycat集群，haproxy(或者lvs)各個(gè)環(huán)節(jié)滅掉了單點(diǎn)，再加上mycat的守護(hù)進(jìn)程，在高可用和負(fù)載均衡上投入到生產(chǎn)都沒啥問題。

我們提供的服務(wù)有：網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)、微信公眾號(hào)開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、諸城ssl等。為千余家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的諸城網(wǎng)站制作公司

但是隨著數(shù)據(jù)量越來越大，數(shù)據(jù)庫越來越多，管理問題就被提上來了。特別是整個(gè)項(xiàng)目組只有你一個(gè)dba的時(shí)候，真的是壓力山大。沒個(gè)工具把整個(gè)集群管起來，效率會(huì)很低。目前我們mycat后面有16個(gè)mysql實(shí)例(只算主的數(shù)量，另有16個(gè)從)，每個(gè)mysql實(shí)例差不多分10個(gè)分庫，合計(jì)約160個(gè)分庫。因?yàn)閱芜壿嫳磉_(dá)到幾十億甚至百億，所以每個(gè)分庫中那些大表還是好幾千萬數(shù)據(jù)量的。

以下是我們遇到的一些問題，所以我只能通過建設(shè)工具平臺(tái)來提高效率。

平臺(tái)的部分功能已經(jīng)投入使用，部分還在開發(fā)，繼續(xù)完善中。這里介紹下我們的幾個(gè)功能：

(說明：我們平臺(tái)的開發(fā)使用非常多的開源程序，我們并不是想要重新造輪子，大部分都是基于現(xiàn)實(shí)問題來做的實(shí)用工具。比如平臺(tái)是在開源程序yearning基礎(chǔ)上擴(kuò)展的，只是做了較大的改動(dòng)，后端還用了inception、mha、gh-ost等等各種開源軟件，最主要的是我們希望基于mycat形成的集群管理，而不是單個(gè)數(shù)據(jù)庫的管理)

一、sql語句審核

我們作為dba角色要考慮的事情，就是幫助開發(fā)寫出高效、正確的sql語句。

開源軟件inception(現(xiàn)在好像閉源了)提供了單庫下的sql審核，但是不針對mycat這種分布式的結(jié)構(gòu)，同時(shí)他也不提供效率的檢查。(不過他的sql規(guī)范性檢查挺好的，我們也在使用。)

在以前作為單庫的時(shí)候，開發(fā)一般寫一個(gè)正確的sql一般沒問題，效率可能差一些。但是分庫之后對開發(fā)是透明的，那就有可能出現(xiàn)問題。

查詢類的sql我們做3點(diǎn)檢查：

1、是否出現(xiàn)了跨庫關(guān)聯(lián)

mycat雖然支持跨庫關(guān)聯(lián)(那也是只支持2表的跨庫)，寫法上也會(huì)不一樣，前面需要加一些注解，另外性能也會(huì)是個(gè)問題。所以我們都是不允許的。

2、sql語句在多少分庫中運(yùn)行，在分庫不是很多的時(shí)候，一個(gè)sql語句在多個(gè)庫中執(zhí)行也許不是問題，但是一旦分庫很多，并且語句查詢量很大時(shí)，對mycat本身會(huì)造成很大的壓力，這回引起mycat的處理能力下降，數(shù)據(jù)返回延時(shí)等。如下面某個(gè)語句我們按照賬號(hào)查詢時(shí)，分析的結(jié)果將是在139個(gè)分庫中執(zhí)行，就會(huì)有存在可能的風(fēng)險(xiǎn)。

3、sql語句在后端數(shù)據(jù)庫執(zhí)行的效率

通常我們會(huì)使用explain檢查sql的執(zhí)行計(jì)劃。

后端有很多分庫的時(shí)候，是否可能存在部分庫索引問題等?

我們的sql語句審核功能中就提供了以上的功能。有了這個(gè)之后開發(fā)人員基本上能自己評估sql了，當(dāng)然最后還是要我審核之后sql才能生效。

根據(jù)我們的分類，sql語句的風(fēng)險(xiǎn)等級分為1-10個(gè)等級，我們可以分級定權(quán)限，比如1級可以讓普通運(yùn)維審核即可，2級以上則需要DBA來審核。

二、DDL操作

假設(shè)要?jiǎng)?chuàng)建一張新表，那么要看這個(gè)表的分庫方式，全局?分片?不分片?等等

如果是全局表或者分庫表，那么我們第一步就是要確定哪些分庫上要建表，沒有工具的話，這并不容易。我們之前寫了一些腳本來幫助我們做這些事情，但是終歸不是很方便。建表之后我們還得往mycat集群上的每個(gè)mycat配置文件中添加表，也不方便。

在建表方面的規(guī)范性,這很重要。比如說我們要使用一些工具如 pt-ocs或者gh-ost，他們都需要主鍵(或者唯一索引)，這些常常被開發(fā)同事所忽略。另外注釋、字符集等等這些更容易被忽略。所以我們特別要感謝下inception這個(gè)工具，可以幫助我們實(shí)施標(biāo)準(zhǔn)規(guī)范。

在ddl方面，如果要對現(xiàn)有的表做修改，這個(gè)更加悲催了，以我們表的規(guī)模，即使分成了100多個(gè)分庫表，每張單表也還是有幾千萬記錄。我們都知道m(xù)ysql上對大表直接操作alter table 是會(huì)造成非?？膳碌暮蠊Ｋ晕覀冞€需要能夠支持批量處理ddl語句的功能。

現(xiàn)在流行的操作方式是借助通過pt-ocs 或者gh-ost 這種開源工具進(jìn)行。gh-ost的侵入更少，更可控，所以我們采用了gh-ost。如頁面上所示，定好時(shí)間，基本上就能自動(dòng)執(zhí)行了。

三、mha高可用，監(jiān)控和操作

我們上面介紹了，使用mha搭建了mysql高可用方案。數(shù)據(jù)庫多了之后，人肉方式的監(jiān)控和執(zhí)行肯定不行的。zabbix和nagios能幫我們建立一些監(jiān)控。執(zhí)行方面，在后臺(tái)命令行方式固然很酷，但是實(shí)例多了之后就不方便。所以我們還得有一個(gè)mha監(jiān)控和操作的平臺(tái)。有了這個(gè)平臺(tái)，有時(shí)候我們需要人工切換的時(shí)候可以直接操作了。這樣即使是普通的運(yùn)維人員，只要授權(quán)就可以進(jìn)行切換.

四、mycat之間的配置同步生效

haproxy將mycat組成了集群，對數(shù)據(jù)庫的請求可能發(fā)往任何一個(gè)mycat服務(wù)，所以必須保證mycat的配置一致性。在單個(gè)mycat情況下，這不是問題，在多個(gè)mycat下這就會(huì)成為一個(gè)風(fēng)險(xiǎn)點(diǎn)。

mycat是通過文件配置的，mycat之間不會(huì)有通信，當(dāng)然也就沒有同步上鎖等待的操作。(據(jù)說2.0版會(huì)開發(fā)mycat集群，也許就沒有這個(gè)問題了)

理想的操作方式：mycat做統(tǒng)一配置，統(tǒng)一配置發(fā)布后，各個(gè)mycat上鎖不允許新的請求進(jìn)來，然后加載新配置，新配置完成并生效后解鎖可用。

現(xiàn)實(shí)的操作方式：選擇在業(yè)務(wù)較為空閑的時(shí)間，在haproxy配置中只保留一個(gè)mycat，其他的全部注釋掉。

其他mycat配置修改并生效之后，放開注釋，原來留下的那個(gè)注釋掉，重載haproxy配置。

將最后那個(gè)mycat配置修改好

最后把全部mycat都放開

這一系列的操作通過手工操作，容易出現(xiàn)紕漏，于是我們把他做成程序的自動(dòng)調(diào)度方式。

建議：如果mycat能夠提供一個(gè)配置版本號(hào)的話，我們更容易檢測(監(jiān)控)到配置是否是最新的。如以時(shí)間戳為版本號(hào)，我們可以比對不同mycat之間是否配置一致。

五、mysql實(shí)例遷移調(diào)度管理

在一個(gè)mysql實(shí)例下運(yùn)行很多庫(database),還是一個(gè)實(shí)例一個(gè)庫?

我們現(xiàn)在的規(guī)模，最大的邏輯庫被分為1百多個(gè)庫，當(dāng)然也有些是單庫，加起來總有個(gè)150個(gè)庫以上。那些比較大的邏輯表，記錄數(shù)一般都是幾十億到百億 。

分庫多了之后就會(huì)帶來一個(gè)問題，我們應(yīng)該起多少個(gè)mysql實(shí)例?

先說現(xiàn)狀：我們現(xiàn)在的規(guī)模是15個(gè)mysql，每個(gè)mysql實(shí)例內(nèi)大約建10個(gè)database。每個(gè)實(shí)例數(shù)據(jù)量大約1T左右。

單個(gè)mysql到1T左右，遷移、備份和恢復(fù)都是有比較大的困難的(別跟說有從庫就不用備份，那是瞎扯)。

現(xiàn)實(shí)是我們每個(gè)mysql都很大，也沒有共享存儲(chǔ)，所以我們無法進(jìn)行快速的調(diào)度(網(wǎng)速也只有千兆，如果數(shù)據(jù)遷移，這個(gè)時(shí)間太長)。

如果將大的mysql實(shí)例分成10個(gè)小的mysql實(shí)例，100G左右的數(shù)據(jù)庫，就會(huì)靈活很多。

假設(shè)每個(gè)mysql能快速調(diào)度到需要的服務(wù)器上(這個(gè)時(shí)間只要小于能容忍的做大時(shí)間)，理論上我們每臺(tái)服務(wù)器可以使用掉90%的資源，一臺(tái)掛掉之后，將該臺(tái)上的10個(gè)mysql分別調(diào)度到其他10臺(tái)服務(wù)器上，這是不是聽起來很棒，但是在4個(gè)9的穩(wěn)定性要求之下，沒有共享存儲(chǔ)這種又是不可能的。

如果每個(gè)庫都獨(dú)立一個(gè)mysql實(shí)例，帶來的問題就是一下子變成150多個(gè)實(shí)例(然后再加上1-2倍的從庫)，就你一個(gè)dba，立馬有種要瘋掉的感覺。

所以我堅(jiān)持了一個(gè)mysql實(shí)例上分多個(gè)庫，即使他單實(shí)例數(shù)據(jù)量大了不方便。

現(xiàn)在我們在平臺(tái)的調(diào)度管理，10個(gè)和100個(gè)沒有什么區(qū)別的時(shí)候，我們就可以把他細(xì)分了。這個(gè)我們暫時(shí)還沒有完成。

問題六、備份與恢復(fù)的管理以及分片后帶來的挑戰(zhàn)

日常備份和恢復(fù)是DBA的一項(xiàng)重要工作，但是自動(dòng)化的備份腳本扔在那里是否執(zhí)行成功呢，備份是否可用呢，這些都是問題。

所以我們需要做一個(gè)備份和恢復(fù)的管理。(備份結(jié)果在mha的圖中有最后備份成功時(shí)間，其他功能正在開發(fā)中)

最后我還想說下在數(shù)據(jù)被分片之后，在備份和恢復(fù)上是帶來很大的問題的。

分片之后數(shù)據(jù)庫多一點(diǎn)沒有關(guān)系，只要我們有管理平臺(tái)就可以。

最大的挑戰(zhàn)是多臺(tái)數(shù)據(jù)庫服務(wù)器之間的備份時(shí)間一致性問題。

事務(wù)型數(shù)據(jù)庫(oltp)中很重要的一個(gè)要求就是數(shù)據(jù)的時(shí)間一致性。

分庫之后，我們能保證的是單庫內(nèi)部的一致性，卻很難保證多庫之間的一致性。

比如:用戶U1的數(shù)據(jù)在D1庫中，用戶U2的數(shù)據(jù)在D2庫中，如果U1和U2之間有關(guān)聯(lián)的交易(如轉(zhuǎn)賬等)。

這個(gè)時(shí)間D1發(fā)生的奔潰，在恢復(fù)的時(shí)候必須保證D1庫和D2庫的時(shí)間點(diǎn)一致性。這很難。

事實(shí)上我們沒有能夠做到這點(diǎn)。

可做的是盡可能的將同一用戶的數(shù)據(jù)存放在一個(gè)庫中，加以訂單表和一些冗余日志進(jìn)行校驗(yàn)恢復(fù)。

這些工作需要在設(shè)計(jì)之初就要考慮。

七、現(xiàn)場慢查詢的查殺

這個(gè)功能很簡單，但是卻非常實(shí)用。

因?yàn)榉謳旌芏啵绻€上出現(xiàn)影響性能的慢查詢，我們需要立刻把他找出來并且殺掉。以前我們手工操作，通過腳本再怎么熟練也需要不少的時(shí)間。

現(xiàn)在頁面上可以一鍵查殺非常方便。

七、數(shù)據(jù)flashback

現(xiàn)在也有開源程序可以實(shí)現(xiàn)對數(shù)據(jù)更新語句的回滾，很好用。

如果是直接通過連接mysql的方式執(zhí)行的語句，我們通?？梢酝ㄟ^連接進(jìn)程號(hào)就能精確的知道具體執(zhí)行的內(nèi)容。

通過mycat中間件之后執(zhí)行的sql語句，就很難獲得非常準(zhǔn)確的內(nèi)容。

這時(shí)只能通過時(shí)間、執(zhí)行的數(shù)據(jù)庫和表名等從每個(gè)mysql上獲得一個(gè)大致范圍，然后通過人工刷選進(jìn)行確認(rèn)。(這個(gè)功能還未完成)

其他還有很多我們需要的功能，目前是列了一堆計(jì)劃，如果你有興趣，可以給我提提意見。