Oracle / MySQL 數據庫高可用方案三大難點問題

以下內容由社區專家岳彩波根據社區交流活動總結

1、超大數據庫的在線遷移問題和歸檔問題

隨著信息的大爆炸，互聯網各種業務的發展，超大、超級大的數據庫都已經出現，先說一下遷移問題，oracle的遷移有很多種方案，遷移T級數據目前有XTTS等官方推薦的一些方案，PB級數據那就需要專業團隊來根據實際情況來做一個完善的遷移方案。目前我也沒接觸過這種數據庫的遷移，希望能和大家共同學習。再來說一下mysql超大的數據庫，T級以上的單數據庫在生產環境中不是很多，所以遷移的難點可能就是在于分庫分表，數據庫一致等問題，在這里分享幾個可用方案：

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語句要快，這里其實倒入也可以使用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

這種方法就是直接復制數據庫的文件結構，要求必須相同的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

其實這個跟方案2是一樣的。只是操作方法不同而已，當然要求也是一樣的。

2、超大數據備份問題

超大數據備份其實和遷移歸檔都能放在一起說，這里單獨拿出來總結一下就是因為備份和遷移畢竟是兩個概念，大家關注的也比較多。

數據備份是容災的基礎，有了備份不等于萬事大吉。因為備份的數據可以還會有其他因素造成的數據損壞，如地震、火災等，對于這些企業應該在數據容災方面提升能力，來進一步應對數據抵抗潛在不安全因素的能力。當然，數據備份還是最基礎的形式，沒有數據備份，任何容災都沒有現實意義。目前來看，主要的數據備份方式如下：

定期磁帶備份：包括遠程磁帶庫、光盤庫備份和遠程關鍵數據+磁帶備份。

數據庫備份：就是在與主數據庫所在生產機相分離的備份機上建立主數據庫的一個拷貝。

網絡數據：這種方式是對生產系統的數據庫數據和所需跟蹤的重要目標文件的更新進行監控與跟蹤，并將更新日志實時通過網絡傳送到備份系統，備份系統則根據日志對磁盤進行更新。

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

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

實時復制：當主中心的數據庫內容被修改時，備份中心的數據庫內容實時地被修改，此種復制方式對網絡可靠性要求高。

定時復制：當主中心的數據庫內容被修改時，備份中心的數據庫內容會按照時間間隔，周期性地按照主中心的更新情況進行刷新，時間間隔可長(幾天或幾個月)可短(幾分鐘或幾秒鐘)。

存儲轉發復制：當主中心的數據庫內容被修改時，主中心的數據庫服務器會先將修改操作Log存儲于本地，待時機成熟再轉發給備份中心。

3、oracle和mysql數據庫在高可用中數據一致性問題

oracle的數據一致性這里就不用說了，已經做的很完善，很少出現問題，出現問題也有完整的方案來解決，主要說一下mysql數據的一致性。就說一下最簡單的mysql主從復制方案吧，供大家參考一下。

現在常用的MySQL高可用方案，十有八九是基于MySQL的主從復制（replication）來設計的，包括常規的一主一從、雙主模式，或者半同步復制（semi-sync replication）。

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

在master上提交事務后，并且寫入binlog，返回事務成功標記；

將binlog發送到slave，轉儲成relay log；

在slave上再將relay log讀取出來應用。

步驟1和步驟3之間是異步進行的，無需等待確認各自的狀態，所以說MySQL replication是異步的。

MySQL semi-sync replication在之前的基礎上做了加強完善，整個流程變成了下面這樣：

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

某個slave連接到master時，會主動告知當前自己是否處于semi-sync模式；

在master上提交事務后，寫入binlog后，還需要通知至少一個slave收到該事務，等待寫入relay log并成功刷新到磁盤后，向master發送“slave節點已完成該事務”確認通知；

master收到上述通知后，才可以真正完成該事務提交，返回事務成功標記；

在上述步驟中，當slave向master發送通知時間超過rpl_semi_sync_master_timeout設定值時，主從關系會從semi-sync模式自動調整成為傳統的異步復制模式。

半同步復制看起來很美好有木有，但如果網絡質量不高，是不是出現抖動，觸發上述第5條的情況，會從半同步復制降級為普通復制；此外，采用半同步復制，會導致master上的tps性能下降非常嚴重，最嚴重的情況下可能會損失50%以上。

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

真想要提高多節點間的數據一致性，可以考慮采用PXC方案。現在已知用PXC規模較大的有qunar、sohu，如果團隊里初期沒有人能比較專注PXC的話，還是要謹慎些，畢竟和傳統的主從復制差異很大，出現問題時需要花費更多精力去排查解決。

上面說完了異步復制、半同步復制、PXC，我們回到主題：在常規的主從復制場景里，如何能保證主從數據的一致性，不要出現數據丟失等問題呢？

在MySQL中，一次事務提交后，需要寫undo、寫redo、寫binlog，寫數據文件等等。在這個過程中，可能在某個步驟發生crash，就有可能導致主從數據的不一致。為了避免這種情況，我們需要調整主從上面相關選項配置，確保即便發生crash了，也不能發生主從復制的數據丟失。

在master上修改配置innodb_flush_log_at_trx_commit = 1sync_binlog = 1上述兩個選項的作用是：保證每次事務提交后，都能實時刷新到磁盤中，尤其是確保每次事務對應的binlog都能及時刷新到磁盤中，只要有了binlog，InnoDB就有辦法做數據恢復，不至于導致主從復制的數據丟失。

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

上述前兩個選項的作用是：確保在slave上和復制相關的元數據表也采用InnoDB引擎，受到InnoDB事務安全的保護，而后一個選項的作用是開啟relay log自動修復機制，發生crash時，會自動判斷哪些relay log需要重新從master上抓取回來再次應用，以此避免部分數據丟失的可能性。

通過上面幾個選項的調整，就可以確保主從復制數據不會發生丟失了。但是，這并不能保證主從數據的絕對一致性，因為，有可能設置了ignoredo ewrite等replication規則，或者某些SQL本身存在不確定因素，或者人為在slave上修改數據，最終導致主從數據不一致。這種情況下，可以采用pt-table-checksum 和 pt-table-sync 工具來進行數據的校驗和修復。

點擊閱讀原文關注社區 高可用技術主題 ，將會不斷更新優質資料、文章，您也可以前往提出疑難問題，與同行切磋交流。

下載 twt 社區客戶端 APP

與更多同行在一起

高手隨時解答你的疑難問題

輕松訂閱各領域技術主題

瀏覽下載最新文章資料

長按識別二維碼即可下載

或到應用商店搜索“twt”

長按二維碼關注公眾號

南京兆柏數據恢復中心 南京兆柏數據恢復中心