前幾天，在首席群里討論，某些人已經實現了在常去的城市都有房產了，出差都有自己的房住（當然有沒有其他的目的就不得而知了）。相較于外出住酒店，兩種方式各有優劣：

• 自有房產是自己的，住著安全放心
• 自有房產需要持續維護：平時需要打掃衛生，交物業費，裝修家具等等
• 在不同城市的自有房產水平不同：房屋面積，裝修家具水平，交通，周邊等等
• 酒店不是自己的，可能有安全風險
• 酒店不需要持續投入，隨到隨住
• 酒店可以提供更多的選擇
• …

上面的內容借用德哥今天公眾號結尾的一句話“其實這段內容（原文為：這篇文章）的內容和標題是匹配的, 只是我還沒想好到底有什么關聯”。
數據庫的高可用究竟是什么，我覺得還是得從實際需求場景來：

• 如果你的業務不允許中斷，那么數據庫的高可用目標就是能夠持續提供數據庫能力
• 如果你的業務允許短時間中斷，那么數據庫的高可用目標就是能夠快速恢復拉起的能力
• 如果你的業務允許較長時間中斷，那么數據庫高可用的目標就是有辦法能夠恢復數據庫即可
• 如果你的業務無關緊要，那么數據庫高可用的目標就是…可以算沒有目標

（Oracle Maximum Availability Architecture (MAA)）

那么從我個人角度以盡可能高的要求來看看數據庫的高可用。

1 主從架構

（MySQL Replication）

主從架構是我們用的比較多的高可用架構，除了上圖MySQL Replication，Oracle有(Active) DataGuard，PostgreSQL也有類似的主從架構。主從架構的優點其實是架構簡單，大多數主從架構除了可以實現異地的數據容災以外，也可以提供讀寫分離的能力（即主寫備讀），提升數據庫整體性能表現。
主從架構主要需要考慮的問題是在switchover或failover后，應用能夠正確連接到正確角色的數據庫上，在這一點上MySQL提供了MySQL Router，三方開源則有MHA和Orchestrator等；Oracle則有TAC和GDS等。

2 集群

這里說的集群要區分于分布式架構，主要涉及MySQL Group Replication（MGR）和Oracle RAC架構等。

（Oracle Real Application Cluster (RAC)）

這里的集群主要是在實例級別提供高可用，即集群內部分實例故障，不影響數據庫提供服務。但在RAC架構中仍可能有存儲的單點故障，因此存儲側也應該實現高可用。當然在集群之上也可以和主從架構配合使用，提供異地容災能力。

（Oracle RAC+DG）

3 分布式

無論是Redis、MongoDB還是大量的國產數據庫，都提供了分布式數據庫架構。

（OceanBase 4.x）

其實簡單來看，就是每個分片內以主從或者副本的方式，分片每個節點可以在不同的地域，實現高可用。而數據庫的訪問接口則一般通過分布式集群本身來管理并提供服務。分布式架構中，只要不是某個分片的所有節點全掛的情況出現，理論上不會出現數據庫異常。

4 誤區

前兩天一朋友的數據庫通過主從架構上線實現了國產數據庫的上線，本是一件好事，但是有些人卻說，不是分布式，高可用不行啊。其實反觀下整體架構，這些人為啥看不到，別人用1+1的節點解決了分布式需要10+臺服務器才能解決的問題。不得不說，分布式數據庫在高可用上看似非常美好，但是節點數量的提升帶來的管理壓力提升、元數據維護增加、網絡壓力增大等，而且分布式不一定適合所有應用場景產生的數據結構和業務場景（這里還不考慮業務代碼變更）。

5 光是數據庫？

舉個栗子，數據庫實現異地容災，且前端應用可以自動連接到對應角色的實例。但是業務應用程序卻只部署在了一個地方，那么如果這個地方整個IDC出現異常，那么前端業務同樣不可能實現容災切換，所以應用程序也需要多地部署。

總結

本期淺談了一下數據庫的高可用，我認為一切還是從需求出發，結合可接受成本來做高可用。
老規矩，知道寫了些啥。