⑴ 資料庫服務的高可用性有幾種方式
高可用性，雖然我不熟悉oracle的，但是sql server的我大概了解一些。分享些我的經驗給你。
高可用性，一般重點有2個，集群負載性能，和讀寫分離。
在不考慮硬體配置的情況下，高可用性要關注的是 哪些是讀寫資料庫，哪些是只讀資料庫。
微軟sql server的最新版本完善了always on功能
方法一般情況都是 （簡單點）
1.有一個主資料庫，做集群 這個集群是用來做災難恢復的建2+個節點，防止主資料庫掛掉
2. 建個鏡像資料庫，用作子資料庫。萬一主庫全掛了，鏡像資料庫（只讀）會重設為（讀寫）
3. 讀寫分離，抽取主數據的log用來還原出鏡像只讀資料庫，為後端數據倉庫用
第二點里可以也為鏡像資料庫建立集群用作災備
⑵ MySQL高可用性保障您業務的安全和穩定性mysqlha
MySQL高可用性：保障您業務的安全和穩定性
MySQL是一款廣泛應用於web開發領域的開源關系型資料庫管理系統，因其穩定、易用、免費開源等優勢，被廣泛使用。在網站、電商等業務中，數據安全性和穩定性是基本要求，一旦資料庫發生故障，將會給業務帶來巨大影響。因此，資料庫的高可用性成為了業務安全、穩定運行的重要保證。
MySQL的高可用性是指在系統的運行中，若主資料庫出現宕機、癱瘓等意外情況時，必須有其他備用資料庫頂替主資料庫，確保業務操作不受影響。下面，將介紹若干種MySQL高可用性的實現方案。
1. 主從復制
主從復制是MySQL的一種高可用性的方案，由一個主資料庫和多個從資料庫組成，主資料庫向從資料庫傳輸數據。當主資料庫宕機時，從資料庫可自動升級為主資料庫，保證了業務的連續性。主從復制機制步驟如下：
1) 主資料庫記錄二進制日誌(master_log);
2) 從資料庫連接到主資料庫，取得二進制日誌(master_log)；
3) 從資料庫「relay」二進制日誌；
4) 從資料庫重放二進制日誌到自己的數據文件；
5) 從資料庫能與主資料庫保持同步，如果主資料庫發生宕機等故障，從資料庫將既可以繼續提供服務，也可以升級為新的主資料庫。
代碼：
主資料庫配置：
# 運行日誌
log-bin=/var/lib/mysql/log/binlog/mysql-bin
# 主伺服器ID，每個伺服器必須有一個唯一的ID
server-id=1
# 同步校驗碼
binlog-do-db=db_demo
從資料庫配置：
# 資料庫主機ip,即主伺服器的ip
master-host=127.0.0.1
# master伺服器ssh的埠號
master-port=3306
# 主伺服器replicatiion用戶密碼
master-user=replication
master-password=123456
# 運行日誌
log-bin=/var/lib/mysql/log/binlog/mysql-bin
# 從伺服器ID，必須唯一的
server-id=2
# 從伺服器同步的資料庫名
replicate-do-db=db_demo
2. 主主復制
主主復制是指環狀復制，即使用多個MySQL主資料庫互相完成同步，從任何一台主資料庫讀寫操作均可。主主復制機制步驟如下：
1) 主資料庫1和主資料庫2完成數據同步;
2) 客戶端會隨機讀寫任何一台主資料庫，實現了讀寫分離的高可用性；
3) 當主資料庫1或主資料庫2宕機時，系統仍能正常運行。
代碼：
主資料庫1配置：
# 運行日誌
log-bin=/var/lib/mysql/log/binlog/mysql-bin
# 主伺服器ID，每個伺服器必須有一個唯一的ID
server-id=1
# 同步校驗碼
binlog-do-db=db_demo
# B的主機名
master-host=192.168.100.101
master-port=3306
master-user=replication
master-password=123456
主資料庫2配置：
# 運行日誌
log-bin=/var/lib/mysql/log/binlog/mysql-bin
# 主伺服器ID，每個伺服器必須有一個唯一的ID
server-id=2
# 同步校驗碼
binlog-do-db=db_demo
# A的主機ip
master-host=192.168.100.100
master-port=3306
master-user=replication
master-password=123456
3. MySQL集群
MySQL集群是指多台MySQL伺服器組成整體，形成類似於一個資料庫伺服器的形象，實現了多台伺服器的負載均衡和高可用性。MySQL集群主要方案包括PXC、Galera。MySQL集群機制步驟如下：
1) 提供統一的IP地址和埠號，讓客戶端通過這個地址和埠號來訪問MySQL集群；
2) 對MySQL集群進行監控，當MySQL集群中一台或多台伺服器宕機或出現故障時，可自動檢查並關閉出故障的MySQL服務節點，並自動轉移服務到正常的MySQL節點上；
3) 在MySQL集群中，每個MySQL節點都安裝了MySQL服務，且伺服器之間有較高的網路延遲。
MySQL集群方案需要實現如下幾個步驟：
1) 安裝和配置MySQL集群軟體，如PXC、Galera等；
2) 創建MySQL節點；
3) 設置各個MySQL節點的角色或權重，如負載均衡、讀寫分離、故障轉移等；
4) 對整個MySQL集群進行監控。
代碼：
配置集群環境
[root@node1 ~]# yum -y install http://repo.percona.com/release/
yum/percona-release-0.0-1.x86_64.rpm
[root@node1 ~]# yum -y install Percona-XtraDB-Cluster-57
啟動集群
啟動PXC服務有如下注意事項：
1. PXC支持多節點一起啟動，只需要指定gcomm://節點IP:port/等信息即可。例如：
[root@node1 ~]# service mysql bootstrap-pxc
[root@node2 ~]# service mysql join-pxc
[root@node3 ~]# service mysql join-pxc
2. 第一次啟動完成後，還需要通過地址授權等操作，使得新建用戶的數據可以在其他節點同步；
3. 對於第一個節點，可能會出現日誌無法復制的情況，需要將log_slave_updates參數設置為ON來強制復制；
4. 可以使用pxc_maget工具對集群進行管理，包括添加節點、刪除節點、修改權重等。
⑶ 五大常見的MySQL高可用方案(最全)
1. 概述
我們在考慮MySQL資料庫的高可用的架構時，主要要考慮如下幾方面：
如果資料庫發生了宕機或者意外中斷等故障，能盡快恢復資料庫的可用性，盡可能的減少停機時間，保證業務不會因為資料庫的故障而中斷。
用作備份、只讀副本等功能的非主節點的數據應該和主節點的數據實時或者最終保持一致。
當業務發生資料庫切換時，切換前後的資料庫內容應當一致，不會因為數據缺失或者數據不一致而影響業務。
關於對高可用的分級在這里我們不做詳細的討論，這里只討論常用高可用方案的優缺點以及高可用方案的選型。
2. 高可用方案
2.1. 主從或主主半同步復制
使用雙節點資料庫，搭建單向或者雙向的半同步復制。在5.7以後的版本中，由於lossless replication、logical多線程復制等一些列新特性的引入，使得MySQL原生半同步復制更加可靠。
常見架構如下：
通常會和proxy、keepalived等第三方軟體同時使用，即可以用來監控資料庫的 健康 ，又可以執行一系列管理命令。如果主庫發生故障，切換到備庫後仍然可以繼續使用資料庫。
優點：
架構比較簡單，使用原生半同步復製作為數據同步的依據；
雙節點，沒有主機宕機後的選主問題，直接切換即可；
雙節點，需求資源少，部署簡單；
缺點：
完全依賴於半同步復制，如果半同步復制退化為非同步復制，數據一致性無法得到保證；
需要額外考慮haproxy、keepalived的高可用機制。
2.2. 半同步復制優化
半同步復制機制是可靠的。如果半同步復制一直是生效的，那麼便可以認為數據是一致的。但是由於網路波動等一些客觀原因，導致半同步復制發生超時而切換為非同步復制，那麼這時便不能保證數據的一致性。所以盡可能的保證半同步復制，便可提高數據的一致性。
該方案同樣使用雙節點架構，但是在原有半同復制的基礎上做了功能上的優化，使半同步復制的機制變得更加可靠。
可參考的優化方案如下：
2.2.1. 雙通道復制
半同步復制由於發生超時後，復制斷開，當再次建立起復制時，同時建立兩條通道，其中一條半同步復制通道從當前位置開始復制，保證從機知道當前主機執行的進度。另外一條非同步復制通道開始追補從機落後的數據。當非同步復制通道追趕到半同步復制的起始位置時，恢復半同步復制。
2.2.2. binlog文件伺服器
搭建兩條半同步復制通道，其中連接文件伺服器的半同步通道正常情況下不啟用，當主從的半同步復制發生網路問題退化後，啟動與文件伺服器的半同步復制通道。當主從半同步復制恢復後，關閉與文件伺服器的半同步復制通道。
優點：
雙節點，需求資源少，部署簡單；
架構簡單，沒有選主的問題，直接切換即可;
相比於原生復制，優化後的半同步復制更能保證數據的一致性。
缺點：
需要修改內核源碼或者使用mysql通信協議。需要對源碼有一定的了解，並能做一定程度的二次開發。
依舊依賴於半同步復制，沒有從根本上解決數據一致性問題。
2.3. 高可用架構優化
將雙節點資料庫擴展到多節點資料庫，或者多節點資料庫集群。可以根據自己的需要選擇一主兩從、一主多從或者多主多從的集群。
由於半同步復制，存在接收到一個從機的成功應答即認為半同步復製成功的特性，所以多從半同步復制的可靠性要優於單從半同步復制的可靠性。並且多節點同時宕機的幾率也要小於單節點宕機的幾率，所以多節點架構在一定程度上可以認為高可用性是好於雙節點架構。
但是由於資料庫數量較多，所以需要資料庫管理軟體來保證資料庫的可維護性。可以選擇MMM、MHA或者各個版本的proxy等等。常見方案如下：
2.3.1. MHA+多節點集群
MHA Manager會定時探測集群中的master節點，當master出現故障時，它可以自動將最新數據的slave提升為新的master，然後將所有其他的slave重新指向新的master，整個故障轉移過程對應用程序完全透明。
MHA Node運行在每台MySQL伺服器上，主要作用是切換時處理二進制日誌，確保切換盡量少丟數據。
MHA也可以擴展到如下的多節點集群：
優點：
可以進行故障的自動檢測和轉移;
可擴展性較好，可以根據需要擴展MySQL的節點數量和結構;
相比於雙節點的MySQL復制，三節點/多節點的MySQL發生不可用的概率更低
缺點：
至少需要三節點，相對於雙節點需要更多的資源;
邏輯較為復雜，發生故障後排查問題，定位問題更加困難;
數據一致性仍然靠原生半同步復制保證，仍然存在數據不一致的風險;
可能因為網路分區發生腦裂現象;
2.3.2. zookeeper+proxy
Zookeeper使用分布式演算法保證集群數據的一致性，使用zookeeper可以有效的保證proxy的高可用性，可以較好的避免網路分區現象的產生。
優點：
較好的保證了整個系統的高可用性，包括proxy、MySQL;
擴展性較好，可以擴展為大規模集群;
缺點：
數據一致性仍然依賴於原生的mysql半同步復制;
引入zk，整個系統的邏輯變得更加復雜;
2.4. 共享存儲
共享存儲實現了資料庫伺服器和存儲設備的解耦，不同資料庫之間的數據同步不再依賴於MySQL的原生復制功能，而是通過磁碟數據同步的手段，來保證數據的一致性。
2.4.1. SAN共享儲存
SAN的概念是允許存儲設備和處理器（伺服器）之間建立直接的高速網路（與LAN相比）連接，通過這種連接實現數據的集中式存儲。常用架構如下：
使用共享存儲時，MySQL伺服器能夠正常掛載文件系統並操作，如果主庫發生宕機，備庫可以掛載相同的文件系統，保證主庫和備庫使用相同的數據。
優點：
兩節點即可，部署簡單，切換邏輯簡單；
很好的保證數據的強一致性；
不會因為MySQL的邏輯錯誤發生數據不一致的情況；
缺點：
需要考慮共享存儲的高可用；
價格昂貴；
2.4.2. DRBD磁碟復制
DRBD是一種基於軟體、基於網路的塊復制存儲解決方案，主要用於對伺服器之間的磁碟、分區、邏輯卷等進行數據鏡像，當用戶將數據寫入本地磁碟時，還會將數據發送到網路中另一台主機的磁碟上，這樣的本地主機(主節點)與遠程主機(備節點)的數據就可以保證實時同步。常用架構如下：
當本地主機出現問題，遠程主機上還保留著一份相同的數據，可以繼續使用，保證了數據的安全。
DRBD是linux內核模塊實現的快級別的同步復制技術，可以與SAN達到相同的共享存儲效果。
優點：
兩節點即可，部署簡單，切換邏輯簡單；
相比於SAN儲存網路，價格低廉；
保證數據的強一致性；
缺點：
對io性能影響較大；
從庫不提供讀操作；
2.5. 分布式協議
分布式協議可以很好解決數據一致性問題。比較常見的方案如下：
2.5.1. MySQL cluster
MySQL cluster是官方集群的部署方案，通過使用NDB存儲引擎實時備份冗餘數據，實現資料庫的高可用性和數據一致性。
優點：
全部使用官方組件，不依賴於第三方軟體；
可以實現數據的強一致性；
缺點：
國內使用的較少；
配置較復雜，需要使用NDB儲存引擎，與MySQL常規引擎存在一定差異；
至少三節點；
2.5.2. Galera
基於Galera的MySQL高可用集群， 是多主數據同步的MySQL集群解決方案，使用簡單，沒有單點故障，可用性高。常見架構如下：
優點：
多主寫入，無延遲復制，能保證數據強一致性；
有成熟的社區，有互聯網公司在大規模的使用；
自動故障轉移，自動添加、剔除節點；
缺點：
需要為原生MySQL節點打wsrep補丁
只支持innodb儲存引擎
至少三節點；
2.5.3. POAXS
Paxos 演算法解決的問題是一個分布式系統如何就某個值（決議）達成一致。這個演算法被認為是同類演算法中最有效的。Paxos與MySQL相結合可以實現在分布式的MySQL數據的強一致性。常見架構如下：
優點：
多主寫入，無延遲復制，能保證數據強一致性；
有成熟理論基礎；
自動故障轉移，自動添加、剔除節點；
缺點：
只支持innodb儲存引擎
至少三節點；
3. 總結
隨著人們對數據一致性的要求不斷的提高，越來越多的方法被嘗試用來解決分布式數據一致性的問題，如MySQL自身的優化、MySQL集群架構的優化、Paxos、Raft、2PC演算法的引入等等。
而使用分布式演算法用來解決MySQL資料庫數據一致性的問題的方法，也越來越被人們所接受，一系列成熟的產品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越來越多的被大規模使用。
隨著官方MySQL Group Replication的GA，使用分布式協議來解決數據一致性問題已經成為了主流的方向。期望越來越多優秀的解決方案被提出，MySQL高可用問題可以被更好的解決。