mycat實(shí)戰(zhàn)（二）-mysql數(shù)據(jù)庫管理

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

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

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

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

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

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

一、sql語句審核

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

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

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

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

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

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

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

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

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

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

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

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

二、DDL操作

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

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

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

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

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

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

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

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

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

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

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

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

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

將最后那個mycat配置修改好

最后把全部mycat都放開

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

分享題目：mycat實(shí)戰(zhàn)（二）-mysql數(shù)據(jù)庫管理
瀏覽路徑：http://bm7419.com/article40/gegceo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、搜索引擎優(yōu)化、用戶體驗(yàn)、營銷型網(wǎng)站建設(shè)、網(wǎng)站排名、動態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)