「偶遇」 愛可生 與 MYSQL 大型應用

今天「偶遇」 愛可生的技術人員，通過了兩個小時的交流，又重塑的我對大型系統中對MYSQL 的應用， 這絕對不是廣告，這絕對不是廣告，這絕對不是廣告，重要的還的說幾遍。

爲何心甘情願的寫點東西，其實對愛可生的認知早在N年前，培訓MYSQL 就去過漕河涇的愛可生。當時還在一個外企，肯花錢讓我作飛機去魔都。

話歸正題，各家產品中的MYSQL 的複製技術都是同樣的，這是改變不了的，半同步，GTID等等這都是MYSQL中熟知的基本LISTS. 問題是一個小體積的應用和一個大型金融機構使用 MYSQL 系統，就要有本質的區別。尤爲到了銀行級別的應用，各類使用的方式就有更多的發揮的地方和要求的地方。一個簡單的MYSQL 就變得愈加的不簡單。

從FAILOVER 的方式就要有更多的考慮，半同步，MHA，MGR 對小企業也許就夠了，對金融機構，銀行體系那就變得不那麼容易，細節，更多的嚴謹性，就變得不是無關緊要。

一切關於金錢的事情都變得慎重，性能，穩定，高可用，在某些場景相似CAP 的原理，都兼顧是很差實現，在保證某些必需要保證的狀況下，兼顧性能，自動化自愈等等都是一個數據庫打包後的賣點，賣的是什麼，一個整套的方案將一個數據庫某些不能本身實現的功能，加以雕琢和補全。

在技術交流過程當中，關於高可用中的切換，對於大型系統的應用，須要作的更細，考慮的問題更多。數據強一致性，與脫離傳統數據FAILOVER後的切換，都從更底層的MYSQL數據庫系統信息的收集作起。經過RAFT 協議方式進行選擇性的切換。

之前一直認爲ORACLE TO MYSQL （不考慮開發的問題），雖然在系統額擴展性上MYSQL 是有優點的，但穩定性和大型系統的可靠性上，都是ORACLE 能夠吐槽的。如今以爲MYSQL 如此係統化發展下去，這個吐槽的點都會變得「動搖」。

MYSQL 至始至終都在用我很小，但我能夠人多力量大的思路來將系統難題化解，配以開發的微服架構的流行，大型系統的拆分。配角變主角的逆襲，還能被阻擋？

本文分享自微信公衆號 - AustinDatabases（AustinDatabases）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。