作者：明溪源
用 MySQL 數據庫，到底會不會被“卡脖子”？
在近期不明朗的貿易形勢下，一些正在規劃數據庫選型、遷移的用戶，紛紛詢問我們對 MySQL 未來前景的看法。那麼使用 MySQL 數據庫會出現被“卡脖子”的情況嗎？
下面我將從中美當前的一些文件條例以及數據庫技術架構本身的角度爲大家進行解答。
商業風險（美方角度）：
Oracle 公司的數據庫產品中，多數產品受美國出口管控條例（Export Administration Regulations，EAR）管控，Oracle 官方已在今年 8 月更新了其產品對應的出口管控類別編碼（Export Control Classification Number，ECCN，這裏關於 ECCN 的背景和分類我們不展開描述）。
其中，對於 Oracle 數據庫產品線（Oracle 10g 以及以上版本）以及其他配套軟件工具均在 5D992.C 類別中。對於 MySQL 產品線，MySQL 企業版、MySQL 標準版、MySQL 經典版、MySQL 集羣版以及 MySQL 嵌入式版同樣在 5D992.C 類別中，然而，在 Oracle 提供的表單中，並沒有 MySQL 社區版（MySQL Community Edition）的記錄。
http://www.oracle.com/us/prod...
由此可見，MySQL 社區版作爲開源軟件，在 EAR 條例的政策中，有別於 MySQL 企業版等商業軟件。下面是 MySQL 官網關於各 MySQL 版本的介紹，這裏我們不展開描述。
這個時候問題來了，MySQL 項目以及整個開源生態發展到今天，其中關係早已是，你中有我，我中有你，MySQL 中就包含大量第三方組件，這些組件有些作爲功能合入了主版本，如我們今天使用的半同步複製源於 Google；而有些組件則作爲軟件包合入並保留了原有 license，如 innodb 默認使用的異步調用包 libaio。那麼如果這些組件受到 EAR 管控怎麼辦？這時候 MySQL 社區版是否還能和 EAR “劃清界限”？
由於 MySQL 中涉及的第三方軟件太多並且存在持續增加的可能，關於這點我們不能完全給出肯定，但是，我們特別查找了關於出口加密軟件源碼在 EAR(734.17) 中的描述。由於加密軟件與通信安全相關，其管控力度有別於普通軟件，在一定程度上可作爲邊界進行對比參考。（這裏關於加密軟件爲何特殊的緣由我們不展開描述）。
首先，在滿足 EAR(742.15(b)) 要求的前提下，面向公衆開放的加密軟件源代碼不受管控。
https://www.ecfr.gov/cgi-bin/...
接下是 EAR-742.15 的具體內容：
對於加密類軟件，首先需要遵守加密軟件出口 license 條例，其次，每項出口均需要經過二次審查。而對於加密軟件源碼，面向公衆開放的加密軟件源碼，不在 EAR 管控範圍內（當然，這並不意味着它不受美國其它法律條例限制，此處我們不展開描述），但是，使用、修改、發佈這些源碼時，需要向美國商務部相關單位（BIS 和 ENC Encryption Request Coordinator）進行郵件報備。
https://www.ecfr.gov/cgi-bin/...
結合兩方信息，我們在 Oracle 給出的 ECCN 編碼中沒有發現 MySQL 社區版，同時 MySQL 所包含的含加密功能的軟件（如 OpenSSL Kerberos）滿足面向公衆開放源碼的要求。因此，除非 EAR 內容大幅度修改，否則使用 MySQL 社區版，目前不存在EAR管控方面的風險。（這裏可能有同學會提出疑問，關於 MySQL 是否會被閉源，這次我們不進行闡述）。
商業風險（中方角度）：
闡述完美方的文件條例，下面我們對國內的趨勢性文件做一個簡單的說明。2017 年，工業和信息化部和國家發展改革委兩部委正式印發了《信息產業發展指南》，文件中提出“支持開源、開放的開發模式，重點推進雲操作系統、雲中間件、新型數據庫管理系統”。
http://www.miit.gov.cn/n11462...
這表示，開源模式在基礎軟件的發展中已得到認可，近幾年 MySQL 在中大型終端用戶羣體中，除了應用的規模外，應用的深度也在不斷髮展，越來越多的非互聯網行業用戶開始走開源 + 自主管理的整體發展模式，這也使 MySQL 數據庫的生態環境不斷豐富成熟，因此，從近幾年金融、電信等行業的建設成果看，使用 MySQL 並不存在政策風險。
綜上所述，當前環境下，不論從中方或是美方政策視角出發，選擇 MySQL 社區版數據庫，不會存在商業上的風險。
技術可行性（ RTO/RPO 可用性級別）：
最後，從技術架構角度，以 Oracle RAC 爲代表的商業數據庫高可用，通常與存儲設備一同部署，由中高端雙（多）控制器磁盤陣列充當數據的保險箱，因此 RAC 架構是將數據庫的風險轉移到存儲設備，增強了系統故障中的短板（磁盤），本質上是提升了單點抵抗故障的能力，但局部單點故障仍存在。
而 MySQL 高可用架構，如主從複製/組複製，則採用一主多從模式，將一份數據保留到多個位置（銀行業通常採用本地 1 主 1 從 + 同城 2 從的共 4 個庫組成數據庫高可用組），本質上是利用數據冗餘換取更高概率的數據安全，做到避免單點故障。（關於主從複製與組複製和 Oracle RAC 的對比我們不展開討論）。
因此，在架構得當、運維規範的前提下，MySQL 的高可用機制也能提供金融級的保障能力，同時，對於以上高可用功能，MySQL 社區版與 MySQL 企業版完全一致，能夠在不被“卡脖子”的前提下，滿足業務對數據庫的可靠性要求。
附：工行案例 鏈接
https://mp.weixin.qq.com/s/CL...