建站
咨詢
售后
建站咨詢
新聞中心
問題闡述
成都創(chuàng)新互聯(lián)公司主要從事成都網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計(jì)、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)五寨,十年網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):18980820575
Mysql Galera集群是迄今OpenStack服務(wù)***的Mysql部署方案，它基于Mysql/InnoDB，我的OpenStack部署方式從原來的主從復(fù)制轉(zhuǎn)換到Galera的多主模式。
Galera雖然有很多好處，如任何時(shí)刻任何節(jié)點(diǎn)都可讀可寫，無復(fù)制延遲，同步復(fù)制，行級(jí)復(fù)制，但是Galera存在一個(gè)問題，也可以說是在實(shí)現(xiàn) 真正的多主可寫上的折衷權(quán)衡，也就是這個(gè)問題導(dǎo)致在代碼的數(shù)據(jù)庫層的操作需要棄用寫鎖，下面我說一下這個(gè)問題。
這個(gè)問題是Mysql Galera集群不支持跨節(jié)點(diǎn)對(duì)表加鎖，也就是當(dāng)OpenStack一個(gè)組件有兩個(gè)會(huì)話分布在兩個(gè)Mysql節(jié)點(diǎn)上同時(shí)寫入一條數(shù)據(jù)，其中一個(gè)會(huì)話會(huì)遇到 死鎖的情況，也就是得到deadlock的錯(cuò)誤，并且該情況在高并發(fā)的時(shí)候發(fā)生概率很高，在社區(qū)Nova，Neutron該情況的報(bào)告有很多。
這個(gè)行為其實(shí)是Galera預(yù)期的結(jié)果，它是由樂觀鎖并發(fā)控制機(jī)制引起的，當(dāng)發(fā)生多個(gè)事務(wù)進(jìn)行寫操作的時(shí)候，樂觀鎖機(jī)制假設(shè)所有的修改都能 沒有沖突地完成。如果兩個(gè)事務(wù)同時(shí)修改同一個(gè)數(shù)據(jù)，先commit的事務(wù)會(huì)成功，另一個(gè)會(huì)被拒絕，并重新開始運(yùn)行整個(gè)事務(wù)。 在事務(wù)發(fā)生的起始節(jié)點(diǎn)，它可以獲取到所有它需要的鎖，但是它不知道其他節(jié)點(diǎn)的情況，所以它采用樂觀鎖機(jī)制把事務(wù)(在Galera中叫writes et)廣播到所有其他節(jié)點(diǎn)上，看在其他節(jié)點(diǎn)上是否能提交成功。這個(gè)writeset會(huì)在每個(gè)節(jié)點(diǎn)上進(jìn)行驗(yàn)證測(cè)試，來決定該writeset是否被接受， 如果檢驗(yàn)失敗，這個(gè)writeset就會(huì)被拋棄，然后最開始的事務(wù)也會(huì)被回滾;如果檢驗(yàn)成功，事務(wù)就被提交，writeset也被應(yīng)用到其他節(jié)點(diǎn)上。 這個(gè)過程如下圖所示:
在Python的SQLAlchemy庫中，有一個(gè)“with_lockmode(‘update’)”語句，這個(gè)代表SQL語句中的“SELECT … FOR UPDATE”，在我參與過的計(jì)費(fèi)項(xiàng)目和社區(qū)的一些項(xiàng)目的代碼中有大量的該結(jié)構(gòu)，由于寫鎖不能在集群中同步，所以這個(gè)語句在Mysql集群中就沒有得到它應(yīng)有的效果，也就是在語義上有問題，但是***Galera會(huì)通過報(bào)deadlock錯(cuò)誤，只讓一個(gè)commit成功，來保證Mysql集群的ACID性。
一些解決方法
- 把請(qǐng)求發(fā)往一個(gè)節(jié)點(diǎn)，這個(gè)在HAProxy中就可以配置，只設(shè)定一個(gè)節(jié)點(diǎn)為master，其余節(jié)點(diǎn)為backup，HAProxy會(huì)在master失效的時(shí)候 自動(dòng)切換到某一個(gè)backup上，這個(gè)也是很多解決方案目前使用的方法，HAProxy配置如下:
- server xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx:3306 check
- server xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx:3306 check backup
- server xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx:3306 check backup
- 對(duì)OpenStack的所有Mysql操作做讀寫分離，寫操作只在master節(jié)點(diǎn)上，讀操作在所有節(jié)點(diǎn)上做負(fù)載均衡。OpenStack沒有原生支持，但 是有一個(gè)開源軟件可以使用，maxscale。
***解決方法
上面的解決方法只是一些workaround，目前情況下最***的解決方法是使用lock-free的方法來對(duì)數(shù)據(jù)庫進(jìn)行操作，也就是無鎖的方式，這就 需要對(duì)代碼進(jìn)行修改，現(xiàn)在Nova，Neutron，Gnocchi等項(xiàng)目已經(jīng)對(duì)其進(jìn)行了修改。
首先得有一個(gè)retry機(jī)制，也就是讓操作執(zhí)行在一個(gè)循環(huán)中，一旦捕獲到deadlock的error就將操作重新進(jìn)行，這個(gè)在OpenStack的oslo.db中已 經(jīng)提供了相應(yīng)的方法叫wrap_db_retry，是一個(gè)Python裝飾器，使用方法如下:
- from oslo_db import api as oslo_db_api
- @oslo_db_api.wrap_db_retry(max_retries=5, retry_on_deadlock=True,
- retry_on_request=True)
- def db_operations():
- ...
然后在這個(gè)循環(huán)之中我們使用叫做”Compare And Swap(CAS)”的無鎖方法來完成update操作，CAS是***在CPU中使用的，CAS說白了就是先比較，再修改，在進(jìn)行UPDATE操作之前，我們先SELEC T出來一些數(shù)據(jù)，我們叫做期望數(shù)據(jù)，在UPDATE的時(shí)候要去比對(duì)這些期望數(shù)據(jù)，如果期望數(shù)據(jù)有變化，說明有另一個(gè)會(huì)話對(duì)該行進(jìn)行了修改， 那么我們就不能繼續(xù)進(jìn)行修改操作了，只能報(bào)錯(cuò)，然后retry;如果沒變化，我們就可以將修改操作執(zhí)行下去。該行為體現(xiàn)在SQL語句中就是在 UPDATE的時(shí)候加上WHERE語句，如”UPDATE … WHERE …”。
給出一個(gè)計(jì)費(fèi)項(xiàng)目中修改用戶等級(jí)的DB操作源碼:
- @oslo_db_api.wrap_db_retry(max_retries=5, retry_on_deadlock=True,
- retry_on_request=True)
- def change_account_level(self, context, user_id, level, project_id=None):
- session = get_session()
- with session.begin():
- # 在會(huì)話剛開始的時(shí)候，需要先SELECT出來該account的數(shù)據(jù)，也就是期望數(shù)據(jù) account = session.query(sa_models.Account).\
- filter_by(user_id=user_id).\
- one()]
- # 在執(zhí)行UPDATE操作的時(shí)候需要比對(duì)期望數(shù)據(jù)，user_id和level，如果它們變化了，那么rows_update就會(huì)被賦值為0 ,就會(huì)走入retry的邏輯
- params = {'level': level}
- rows_update = session.query(sa_models.Account).\
- filter_by(user_id=user_id).\
- filter_by(level=account.level).\
- update(params, synchronize_session='evaluate')
- # 修改失敗，報(bào)出RetryRequest的錯(cuò)誤，使上面的裝飾器抓獲該錯(cuò)誤，然后重新運(yùn)行邏輯 if not rows_update:
- LOG.debug('The row was updated in a concurrent transaction, '
- 'we will fetch another one')
- raise db_exc.RetryRequest(exception.AccountLevelUpdateFailed())
- return self._row_to_db_account_model(account)
數(shù)據(jù)的一致性問題
該問題在OpenStack郵件列表中有說過，雖然Galera是生成同步的，也就是寫入數(shù)據(jù)同步到整個(gè)集群非?？?，用時(shí)非常短，但既然是分布式系 統(tǒng)，本質(zhì)上還是需要一些時(shí)間的，尤其是在負(fù)載很大的時(shí)候，同步不及時(shí)會(huì)很嚴(yán)重。
所以Galera只是虛擬同步，不是直接同步，也就是會(huì)存在一些gap時(shí)間段，無法讀到寫入的數(shù)據(jù)，Galera提供了一個(gè)配置項(xiàng)，叫做wsrep_sync_ wait，它的默認(rèn)值是0，如果賦值為1，就能夠保證讀寫的一致性，但是會(huì)帶來延遲問題。
文章題目：數(shù)據(jù)庫寫操作棄用“SELECT…FORUPDATE”解決方案
分享鏈接：http://www.dlmjj.cn/article/coccjco.html
