Oracle / MySQL 數(shù)據(jù)庫(kù)高可用方案三大難點(diǎn)問題

以下內(nèi)容由社區(qū)專家岳彩波根據(jù)社區(qū)交流活動(dòng)總結(jié)

1、超大數(shù)據(jù)庫(kù)的在線遷移問題和歸檔問題

隨著信息的大爆炸，互聯(lián)網(wǎng)各種業(yè)務(wù)的發(fā)展，超大、超級(jí)大的數(shù)據(jù)庫(kù)都已經(jīng)出現(xiàn)，先說一下遷移問題，oracle的遷移有很多種方案，遷移T級(jí)數(shù)據(jù)目前有XTTS等官方推薦的一些方案，PB級(jí)數(shù)據(jù)那就需要專業(yè)團(tuán)隊(duì)來根據(jù)實(shí)際情況來做一個(gè)完善的遷移方案。目前我也沒接觸過這種數(shù)據(jù)庫(kù)的遷移，希望能和大家共同學(xué)習(xí)。再來說一下mysql超大的數(shù)據(jù)庫(kù)，T級(jí)以上的單數(shù)據(jù)庫(kù)在生產(chǎn)環(huán)境中不是很多，所以遷移的難點(diǎn)可能就是在于分庫(kù)分表，數(shù)據(jù)庫(kù)一致等問題，在這里分享幾個(gè)可用方案：

In this case, normally, the best solution is a mysqldump using the --tab option like this:

mysqldump --tab=/path/to/serverlocaldir --single-transaction table_a

tab option produce 2 file, one file -table_a.sql- that contains only the table create statement and the oher file -table_a.txt- contains tab-separated data.

Now you can create your new table

create table table_b like table_a;

Then you simply load data in your new table via LOAD DATA without care for the table's name.

LOAD DATA INFILE '/path/to/serverlocaldir/table_a.txt'

INTO TABLE table_b FIELDS TERMINATED BY ' ' ...

LOAD DATA is usually 20 times faster than using INSERT statements.

LOAD DATA速度比INSERT語句要快，這里其實(shí)倒入也可以使用mysqlimport命令

I recently moved a 30GB database with the following stragegy:

Old Server

Stop mysql server

Copy contents of datadir to another location on disk (~/mysqldata/*)

Start mysql server again (downtime was 10-15 minutes)

compress the data (tar -czvf mysqldata.tar.gz ~/mysqldata)

copy the compressed file to new server

New Server

install mysql (don't start)

unzip compressed file (tar -xzvf mysqldata.tar.gz)

move contents of mysqldata to the datadir

Make sure your innodb_log_file_size is same on new server, or if it's not, don't copy the old log files (mysql will generate these)

Start mysql

這種方法就是直接復(fù)制數(shù)據(jù)庫(kù)的文件結(jié)構(gòu)，要求必須相同的mysql版本，和相同的配置才可以用這種方法

方案3

If you are considering migrating to another DB Server with the exact same version of MySQL, you may want torsync the datadir from the old server to the new server.

This will work regardless of InnoDB file layout or even the presence of MyISAM tables.

install the same version of mysql on ServerB that ServerA has

On ServerA, run RESET MASTER; to erase all binary logs before the rsycn process. If binary logging is not enabled, you can skip this step.

On ServerA, run SET GLOBAL innodb_max_dirty_pages_pct = 0; from mysql and about 10 minutes (This purges dirty pages from the InnoDB Buffer Pool. It also helps perform a mysql shutdown faster) If your database is all MyISAM, you can skip this step.

rsync /var/lib/mysql of ServerA to /var/lib/mysql on ServerB

Repeat Step 3 until an rsync takes less than 1 minute

service mysql stop on ServerA

Perform one more rsync

scp ServerA:/etc/my.cnf to ServerB:/etc/.

service mysql start on ServerB

service mysql start on ServerA (optional)

Essentially, here is what such a script would like this

其實(shí)這個(gè)跟方案2是一樣的。只是操作方法不同而已，當(dāng)然要求也是一樣的。

2、超大數(shù)據(jù)備份問題

超大數(shù)據(jù)備份其實(shí)和遷移歸檔都能放在一起說，這里單獨(dú)拿出來總結(jié)一下就是因?yàn)閭浞莺瓦w移畢竟是兩個(gè)概念，大家關(guān)注的也比較多。

數(shù)據(jù)備份是容災(zāi)的基礎(chǔ)，有了備份不等于萬事大吉。因?yàn)閭浞莸臄?shù)據(jù)可以還會(huì)有其他因素造成的數(shù)據(jù)損壞，如地震、火災(zāi)等，對(duì)于這些企業(yè)應(yīng)該在數(shù)據(jù)容災(zāi)方面提升能力，來進(jìn)一步應(yīng)對(duì)數(shù)據(jù)抵抗?jié)撛诓话踩蛩氐哪芰Α．?dāng)然，數(shù)據(jù)備份還是最基礎(chǔ)的形式，沒有數(shù)據(jù)備份，任何容災(zāi)都沒有現(xiàn)實(shí)意義。目前來看，主要的數(shù)據(jù)備份方式如下：

定期磁帶備份：包括遠(yuǎn)程磁帶庫(kù)、光盤庫(kù)備份和遠(yuǎn)程關(guān)鍵數(shù)據(jù)+磁帶備份。

數(shù)據(jù)庫(kù)備份：就是在與主數(shù)據(jù)庫(kù)所在生產(chǎn)機(jī)相分離的備份機(jī)上建立主數(shù)據(jù)庫(kù)的一個(gè)拷貝。

網(wǎng)絡(luò)數(shù)據(jù)：這種方式是對(duì)生產(chǎn)系統(tǒng)的數(shù)據(jù)庫(kù)數(shù)據(jù)和所需跟蹤的重要目標(biāo)文件的更新進(jìn)行監(jiān)控與跟蹤，并將更新日志實(shí)時(shí)通過網(wǎng)絡(luò)傳送到備份系統(tǒng)，備份系統(tǒng)則根據(jù)日志對(duì)磁盤進(jìn)行更新。

遠(yuǎn)程鏡像：通過高速光纖通道線路和磁盤控制技術(shù)將鏡像磁盤延伸到遠(yuǎn)離生產(chǎn)機(jī)的地方，鏡像磁盤數(shù)據(jù)與主磁盤數(shù)據(jù)完全一致，更新方式為同步或異步。

這些措施能夠在系統(tǒng)發(fā)生故障后進(jìn)行系統(tǒng)恢復(fù)。但是這些措施一般只能處理計(jì)算機(jī)單點(diǎn)故障，對(duì)區(qū)域性、毀滅性災(zāi)難則束手無策，也不具備災(zāi)難恢復(fù)能力。所以我們就需要建立異地容災(zāi)中心，做數(shù)據(jù)的遠(yuǎn)程備份，在災(zāi)難發(fā)生之后要確保原有的數(shù)據(jù)不會(huì)丟失或者遭到破壞。建立的異地容災(zāi)中心可以簡(jiǎn)單地把它理解成一個(gè)遠(yuǎn)程的數(shù)據(jù)備份中心。數(shù)據(jù)容災(zāi)的恢復(fù)時(shí)間比較長(zhǎng)，但是相比其他容災(zāi)級(jí)別來講它的費(fèi)用比較低，而且構(gòu)建實(shí)施也相對(duì)簡(jiǎn)單。主要的實(shí)施方法如下：

實(shí)時(shí)復(fù)制：當(dāng)主中心的數(shù)據(jù)庫(kù)內(nèi)容被修改時(shí)，備份中心的數(shù)據(jù)庫(kù)內(nèi)容實(shí)時(shí)地被修改，此種復(fù)制方式對(duì)網(wǎng)絡(luò)可靠性要求高。

定時(shí)復(fù)制：當(dāng)主中心的數(shù)據(jù)庫(kù)內(nèi)容被修改時(shí)，備份中心的數(shù)據(jù)庫(kù)內(nèi)容會(huì)按照時(shí)間間隔，周期性地按照主中心的更新情況進(jìn)行刷新，時(shí)間間隔可長(zhǎng)(幾天或幾個(gè)月)可短(幾分鐘或幾秒鐘)。

存儲(chǔ)轉(zhuǎn)發(fā)復(fù)制：當(dāng)主中心的數(shù)據(jù)庫(kù)內(nèi)容被修改時(shí)，主中心的數(shù)據(jù)庫(kù)服務(wù)器會(huì)先將修改操作Log存儲(chǔ)于本地，待時(shí)機(jī)成熟再轉(zhuǎn)發(fā)給備份中心。

3、oracle和mysql數(shù)據(jù)庫(kù)在高可用中數(shù)據(jù)一致性問題

oracle的數(shù)據(jù)一致性這里就不用說了，已經(jīng)做的很完善，很少出現(xiàn)問題，出現(xiàn)問題也有完整的方案來解決，主要說一下mysql數(shù)據(jù)的一致性。就說一下最簡(jiǎn)單的mysql主從復(fù)制方案吧，供大家參考一下。

現(xiàn)在常用的MySQL高可用方案，十有八九是基于MySQL的主從復(fù)制（replication）來設(shè)計(jì)的，包括常規(guī)的一主一從、雙主模式，或者半同步復(fù)制（semi-sync replication）。

我們常常把MySQL replication說成是MySQL同步（sync），但事實(shí)上這個(gè)過程是異步（async）的。大概過程是這樣的：

在master上提交事務(wù)后，并且寫入binlog，返回事務(wù)成功標(biāo)記；

將binlog發(fā)送到slave，轉(zhuǎn)儲(chǔ)成relay log；

在slave上再將relay log讀取出來應(yīng)用。

步驟1和步驟3之間是異步進(jìn)行的，無需等待確認(rèn)各自的狀態(tài)，所以說MySQL replication是異步的。

MySQL semi-sync replication在之前的基礎(chǔ)上做了加強(qiáng)完善，整個(gè)流程變成了下面這樣：

首先，master和至少一個(gè)slave都要啟用semi-sync replication模式；

某個(gè)slave連接到master時(shí)，會(huì)主動(dòng)告知當(dāng)前自己是否處于semi-sync模式；

在master上提交事務(wù)后，寫入binlog后，還需要通知至少一個(gè)slave收到該事務(wù)，等待寫入relay log并成功刷新到磁盤后，向master發(fā)送“slave節(jié)點(diǎn)已完成該事務(wù)”確認(rèn)通知；

master收到上述通知后，才可以真正完成該事務(wù)提交，返回事務(wù)成功標(biāo)記；

在上述步驟中，當(dāng)slave向master發(fā)送通知時(shí)間超過rpl_semi_sync_master_timeout設(shè)定值時(shí)，主從關(guān)系會(huì)從semi-sync模式自動(dòng)調(diào)整成為傳統(tǒng)的異步復(fù)制模式。

半同步復(fù)制看起來很美好有木有，但如果網(wǎng)絡(luò)質(zhì)量不高，是不是出現(xiàn)抖動(dòng)，觸發(fā)上述第5條的情況，會(huì)從半同步復(fù)制降級(jí)為普通復(fù)制；此外，采用半同步復(fù)制，會(huì)導(dǎo)致master上的tps性能下降非常嚴(yán)重，最嚴(yán)重的情況下可能會(huì)損失50%以上。

這樣來看，除非需要非常嚴(yán)格保證數(shù)據(jù)一致性等迫不得已的場(chǎng)景，就不太建議使用半同步復(fù)制了。當(dāng)然了，事實(shí)上我們也可以通過加強(qiáng)程序端的邏輯控制，來避免主從數(shù)據(jù)不一致時(shí)發(fā)生邏輯錯(cuò)誤，比如說如果在從上讀取到的數(shù)據(jù)和主不一致的話，那么就觸發(fā)主從間的一次數(shù)據(jù)修復(fù)工作。或者，我們也可以用 pt-table-checksum & pt-table-sync 兩個(gè)工具來校驗(yàn)并修復(fù)數(shù)據(jù)，只要運(yùn)行頻率適當(dāng)，是可行的。

真想要提高多節(jié)點(diǎn)間的數(shù)據(jù)一致性，可以考慮采用PXC方案。現(xiàn)在已知用PXC規(guī)模較大的有qunar、sohu，如果團(tuán)隊(duì)里初期沒有人能比較專注PXC的話，還是要謹(jǐn)慎些，畢竟和傳統(tǒng)的主從復(fù)制差異很大，出現(xiàn)問題時(shí)需要花費(fèi)更多精力去排查解決。

上面說完了異步復(fù)制、半同步復(fù)制、PXC，我們回到主題：在常規(guī)的主從復(fù)制場(chǎng)景里，如何能保證主從數(shù)據(jù)的一致性，不要出現(xiàn)數(shù)據(jù)丟失等問題呢？

在MySQL中，一次事務(wù)提交后，需要寫undo、寫redo、寫binlog，寫數(shù)據(jù)文件等等。在這個(gè)過程中，可能在某個(gè)步驟發(fā)生crash，就有可能導(dǎo)致主從數(shù)據(jù)的不一致。為了避免這種情況，我們需要調(diào)整主從上面相關(guān)選項(xiàng)配置，確保即便發(fā)生crash了，也不能發(fā)生主從復(fù)制的數(shù)據(jù)丟失。

在master上修改配置innodb_flush_log_at_trx_commit = 1sync_binlog = 1上述兩個(gè)選項(xiàng)的作用是：保證每次事務(wù)提交后，都能實(shí)時(shí)刷新到磁盤中，尤其是確保每次事務(wù)對(duì)應(yīng)的binlog都能及時(shí)刷新到磁盤中，只要有了binlog，InnoDB就有辦法做數(shù)據(jù)恢復(fù)，不至于導(dǎo)致主從復(fù)制的數(shù)據(jù)丟失。

在slave上修改配置master_info_repository = "TABLE"relay_log_info_repository = "TABLE"relay_log_recovery = 1

上述前兩個(gè)選項(xiàng)的作用是：確保在slave上和復(fù)制相關(guān)的元數(shù)據(jù)表也采用InnoDB引擎，受到InnoDB事務(wù)安全的保護(hù)，而后一個(gè)選項(xiàng)的作用是開啟relay log自動(dòng)修復(fù)機(jī)制，發(fā)生crash時(shí)，會(huì)自動(dòng)判斷哪些relay log需要重新從master上抓取回來再次應(yīng)用，以此避免部分?jǐn)?shù)據(jù)丟失的可能性。

通過上面幾個(gè)選項(xiàng)的調(diào)整，就可以確保主從復(fù)制數(shù)據(jù)不會(huì)發(fā)生丟失了。但是，這并不能保證主從數(shù)據(jù)的絕對(duì)一致性，因?yàn)椋锌赡茉O(shè)置了ignoredo ewrite等replication規(guī)則，或者某些SQL本身存在不確定因素，或者人為在slave上修改數(shù)據(jù)，最終導(dǎo)致主從數(shù)據(jù)不一致。這種情況下，可以采用pt-table-checksum 和 pt-table-sync 工具來進(jìn)行數(shù)據(jù)的校驗(yàn)和修復(fù)。

點(diǎn)擊閱讀原文關(guān)注社區(qū) 高可用技術(shù)主題 ，將會(huì)不斷更新優(yōu)質(zhì)資料、文章，您也可以前往提出疑難問題，與同行切磋交流。

下載 twt 社區(qū)客戶端 APP

與更多同行在一起

高手隨時(shí)解答你的疑難問題

輕松訂閱各領(lǐng)域技術(shù)主題

瀏覽下載最新文章資料

長(zhǎng)按識(shí)別二維碼即可下載

或到應(yīng)用商店搜索“twt”

長(zhǎng)按二維碼關(guān)注公眾號(hào)

南京兆柏?cái)?shù)據(jù)恢復(fù)中心 南京兆柏?cái)?shù)據(jù)恢復(fù)中心