主從選舉演算法

① 搞懂Redis (八) - 哨兵機制

哨兵的核心功能是主節點的自動故障轉移
下圖是一個典型的哨兵集群監控的邏輯圖

Redis Sentinel包含了若干個Sentinel 節點，這樣做也帶來了兩個好處：

1、 對於節點的故障判斷是由多個sentinel節點共同完成，這樣可以有效地防止誤判
2、即使個別sentinel節點不可用，整個sentinel集群依然是可用的

哨兵實現了以下功能：
1、監控：每個sentinel節點會對數據節點（Redis master/slave節點）和其餘sentinel節點進行監控
2、通知：sentinel節點會將故障轉移的結果通知給應用方
3、故障轉移：實現slave晉升為master，並維護後續正確的主從關系
4、配置中心：在Redis sentinel模式中，客戶端在初始化的時候連接的是sentinel節點集合，從中獲取主節點信息

其中，監控和自動故障轉移功能，使得哨兵可以及時發現主節點故障並完成轉移；而配置中心和通知功能，則需要在與客戶端的交互中才能體現

1、原理
監控
sentinel節點需要監控master、slave以及其他sentinel節點的狀態。這一過程是通過Redis的pubsub系統實現的。Redis sentinel一共有三個定時監控任務，完成對各個節點發現和監控：

主觀/客觀下線

主觀下線

每個sentinel節點，每隔1s會對數據節點發送ping命令做心跳檢測，當這些節點超過down-after-milliseconds沒有進行有效回復時，sentinel節點會對該節點做失敗判定，這叫主觀下線

客觀下線

客觀下線，是指當大多數sentinel節點都認為master節點宕機了，那這個判定就是客觀的，叫客觀下線。
那大多數是指什麼呢？ 其實就是分布式協調中的quorum判定啦，大多數就是指半數。 如哨兵數量是5，那大多數就是5/2+1=3個，哨兵數量是10大多數就是10/2+1=6個。
註：sentinel節點的數量至少為3個，否則不滿足quorum判定條件

哨兵選舉

如果發生了客觀下線，那哨兵節點會選舉出一個leader來進行實際的故障轉移工作。Redis使用了Raft演算法來實現哨兵領導者選舉，大致思路如下：

故障轉移
選舉出的leader sentinel節點將負責故障轉移，也就是進行master/slave節點的主從切換。故障轉移，首先要從slave節點中篩選出一個作為新的master，主要考慮以下slave信息

註：Leader sentinel 節點，會從新的master節點那裡得到一個configuration epoch，本質是個version版本號，每次主從切換的version號都必須是唯一的。其他的哨兵都是根據version來更新自己的master配置

② es源碼筆記-7.x 選主流程

Discovery模塊負責發現集群中的節點，以及選擇主節點。ES支持多種不同Discovery類型選擇，內置的實現有兩種：Zen Discovery和Coordinator，其他的包括公有雲平台亞馬遜的EC2、谷歌的GCE等。

它假定所有節點都有一個唯一的ID，使用該ID對節點進行排序。任何時候的當前Leader都是參與集群的最高ID節點。該演算法的優點是易於實現。但是，當擁有最大ID的節點處於不穩定狀態的場景下會有問題。例如，Master負載過重而假死，集群擁有第二大ID的節點被選為新主，這時原來的Master恢復，再次被選為新主，然後又假死
ES 通過推遲選舉，直到當前的 Master 失效來解決上述問題，只要當前主節點不掛掉，就不重新選主。但是容易產生腦裂（雙主），為此，再通過「法定得票人數過半」解決腦裂問題

1、多數派原則：必須得到超過半數的選票才能成為master。
選出的leader一定擁有最新已提交數據：在raft中，數據更新的節點不會給數據舊的節點投選票，而當選需要多數派的選票，則當選人一定有最新已提交數據。在es中，version大的節點排序優先順序高，同樣用於保證這一點。

正確性論證：raft是一個被論證過正確性的演算法，而ES的演算法是一個沒有經過論證的演算法，只能在實踐中發現問題，做bug fix，這是我認為最大的不同。

是否有選舉周期term：raft引入了選舉周期的概念，每輪選舉term加1，保證了在同一個term下每個參與人只能投1票。ES在選舉時沒有term的概念，不能保證每輪每個節點只投一票。
選舉的傾向性：raft中只要一個節點擁有最新的已提交的數據，則有機會選舉成為master。在ES中，version相同時會按照NodeId排序，總是NodeId小的人優先順序高。

2、Paxos演算法
Paxos非常強大，尤其在什麼時機，以及如何進行選舉方面的靈活性比簡單的Bully演算法有很大的優勢，因為在現實生活中，存在比網路連接異常更多的故障模式。但 Paxos 實現起來非常復雜

本篇只討論內置的Zen Discovery

整體流程可以概括為：選舉臨時Master，如果本節點當選，則等待確立Master，如果其他節點當選，則嘗試加入集群，然後啟動節點失效探測器。

如果集群剛啟動則參與選主，否則加入集群
org.elasticsearch.node.Node.start()

選舉過程的實現位於 org.elasticsearch.discovery.zen.ZenDiscovery.findMaster() ,該函數查找當前集群的活躍 Master，或者從候選者中選擇新的Master。如果選主成功，則返回選定的Master，否則返回空

上面選擇臨時主節點非常簡單，
首先需要判斷當前候選者人數是否達到法定人數，否則選主失敗。

取列表中的最小值，比較函數通過compareNodes實現,只是對節點 ID 進行排序

選舉出的臨時Master有兩種情況：該臨時Master是本節點或非本節點。

（2）超時（默認為30秒，可配置）後還沒有滿足數量的join請求，則選舉失敗，需要進行新一輪選舉。

超時後直接return，當非臨時節點加入集群不成功時，重新發起選主流程
org.elasticsearch.discovery.zen.ZenDiscovery.innerJoinCluster()

（3）成功後發布新的clusterState。
實現如下：

submitStateUpdateTask最終通過TaskBatcher# submitTasks來提交任務。執行任務並發布集群狀態的總體過程在 MasterService#runTasks 方法中實現。

（2）向Master發送加入請求，並等待回復。超時時間默認為1分鍾（可配置），如果遇到異常，則默認重試3次（可配置）。這個步驟在joinElectedMaster方法中實現。

最終當選的Master會先發布集群狀態，才確認客戶的join請求，因此，joinElectedMaster返回代表收到了join請求的確認，並且已經收到了集群狀態。所以如果返回不成功，則重新發起選主流程
（3）檢查收到的集群狀態中的Master節點如果為空，或者當選的Master不是之前選擇的節點，則重新選舉。

1、es通過主從模式以及發現機制保證節點之間的負載均衡，但是es使用量的急劇增加暴露了很多問題，例如，Zen的minimum_master_nodes設置經常配置錯誤，這會使群集更容易出現裂腦和丟失數據的風險
2、7.x以上版本Coordinator提供了安全的亞秒級的master選舉時間，而Zen可能要花幾秒鍾來選擇一個新的master
3、es的master掛了，數據節點在這區間還能對外提供服務嗎？
參考
Elasticsearch分布式一致性原理剖析

③ DR與BDR有什麼作用如何選舉

DR和BDR的選舉是根據優先順序來確定的，優先順序越大約有可能成為DR，如果優先順序相同，那麼就根據route-id的大小來選舉，越大越有可能成為DR。
首先，所有路由器向外發送hello包的時候，每個路由器都認為自己是DR，這個時候的狀態為init，當達到2-way狀態時，已經是鄰居關系，這個時候在你給我發的數據包中我能看見我自己的信息。這個時候誰的優先順序大誰是DR，如果優先順序相同就比較route-id。
如果主從關系確定後，一個新加入的路由器比DR優先順序大，那麼原有的DR還是DR.只有當DR掛掉後，原有的bdr會向外發送其優先順序route-id和其他路由器對比，如果該BDR優先順序高，那麼繼任DR的工作。
這里有一點需要明確：優先順序都為0的時候，不能參與主從選舉。drther都是優先順序為0.
drther和dr通訊的組播地址是：224.0.0.6.
其餘的都是224.0.0.6.

希望樓主好好看看卷一。
網路之路慢慢長，我們共勉吧

④ mysql group replication自動主從切換嗎

mysql> show processlist\G
*************************** 1. row ***************************
Id: 3
User: system user
Host:
db: NULL
Command: Connect
Time: 2601
State: Slave has read all relay log; waiting for the slave I/O thread to update it
Info: NULL
*************************** 2. row ***************************
Id: 4
User: root
Host: localhost
db: NULL
Command: Query

⑤ 常見分布式集群選舉機制總結

1，Zookeeper -- paxos

2，kafka -- zookeeper上創建節點

3，redis -- 哨兵模式

4，Eureka -- 相互復制

我們探討這幾個集群的選舉機制，其實就是探討它們的高可用性。如果集群中的某些節點掛了，如何保證可用性？這個問題是分布式系統面臨的三大問題之一。

Zookeeper的leader選舉機制，是這四種集群中最復雜的選舉機制，同時也是這四種集群中最接近paxos演算法的實現。相比於Zookeeper的選舉機制，kafka集群、redis集群、Eureka集群的選舉機制簡單了許多。

Zookeeper的leader選舉是Zookeeper實現數據一致性的關鍵，同時也存在一些問題。認清Zookeeper的優點與缺陷，對於我們使用好它還是很有必要的。

Zookeeper的選舉機制有2個觸發條件：集群啟動階段和集群運行階段leader掛機。這2種場景下選舉的流程基本一致，我們以集群運行階段leader掛機為例來進行說明。leader掛機以後，重新選舉leader，選舉的流程如下：

1，Zookeeper集群中的follower檢測到leader掛機，然後把自己的狀態置為LOOKING，開始進行leader選舉。

2，每台伺服器選舉自己為leader，然後把自己的選票通過廣播通知其他伺服器。

3，每台伺服器接收來自其他伺服器的選票，並進行合法性校驗，主要有兩點校驗，選舉輪次校驗和伺服器的狀態的校驗。

4，處理選票。每台伺服器都會將自己的選票與其他伺服器的選票進行PK，PK的規則如下：

第一個規則：首先進行ZXID的PK，大者獲勝。

第二條規則：如果ZXID相等，則進行myid的PK，大者獲勝。

經過PK以後，如果當前伺服器PK失敗，則會把自己的選票重新投給勝者，然後把更新後的選票通過廣播通知其他伺服器。

5，統計選票。根據超過半數的原則，每台伺服器都會統計leader的選票，如果超過半數，則結束選舉。

6，更新伺服器狀態。follower把自己的狀態更新為FOLLOWING，leader把自己的狀態更新為LEADING。

OK，這就是Zookeeper的leader選舉機制。經過若干輪選舉以後，Zookeeper集群繼續對外提供服務。由於選票PK首先比較的是ZXID，所以Zookeeper能夠保證leader的數據是最新的。

kafka集群是如何保證高可用性的呢？

kafka通過Zookeeper管理集群配置、選舉leader、consumer group發生變化時進行rebalance。

那麼我要問了，kafka是如何選舉leader的呢？

概括來說，Kafka選舉leader的過程是這樣的：kafka的所有broker，在Zookeeper的/controller路徑下創建臨時節點，成功創建的那個broker就會成為leader，其他的broker就會成為follower。

當leader掛機時，臨時節點會被刪除，這是其他節點通過Zookeeper的watch機制，會監聽到leader的變化，然後所有的follower會再次進行leader選舉。

kafka的選舉其實就是創建臨時節點，這和Zookeeper分布式鎖的實現原理基本相同。

redis主從切換和redis集群的理解。

要注意，主從切換默認只有一個master，但是對於多個master的集群，沒有主從切換的說法。

redis沒有類似Zookeeper的選舉機制。redis的master掛掉以後，redis集群是通過主從切換來保證高可用性的。

redis主從切換有2種方式：手動切換和自動切換。

這里我們討論自動切換，redis主從自動切換需要哨兵模式的支持，哨兵模式簡單來說就是：監控master和slave，在master出現故障的時候，自動將slave切換成master，master恢復以後，作為新master的slave對外提供服務。

准確的來說，Eureka集群中的各節點之間不存在主從關系。Eureka集群中的節點的關系是對等的，其他3種集群則都存在主從關系，這是Eureka集群的一個特色。

Eureka集群的各個server之間通過相互注冊的方式來實現集群的高可用性。數據同步的方式是增量備份，這樣可以保證每個server都是最新最全的數據。從而保證集群的高可用性。這樣即使某個server掛了，集群還可以對外提供服務。

Eureka有一個配置項：eureka.client.fetch-register，是否從Eureka server獲取注冊信息。如果我們是Eureka集群，那麼該項配置為true。這樣Eureka server直接就可以相互注冊。

OK，這篇文章只是對4種集群的選舉機制進行了一個概括性的介紹，具體細節還是很復雜的。之前有文章重點分析過Zookeeper的leader選舉，後續還會另起文章分析其他幾種集群的選舉機制，到時候我們再進行更深入的講解。

⑥ ospf多路訪問鏈路中的主從關系

DR(指定路由器)與BDR（備用指定路由器）說是主從關系不確切的，他們的關系應該是主力與替補的關系。
OSPF協議用的是比較高級的SPF演算法，因為此協議為了好管理把埠們劃分為一個個單位，稱為域（area）。因為SPF演算法很佔用路由器的內存空間並且OSPF網路環境復雜，為了節省空間，每個域里只要有1個路由器知道外面的情況的就可以了，這個路由器就叫DR了。域里其他的路由器只要知道域內情況就可以了。
可是誰又能保證DR不會壞呢？所以要有個替補，這就是BDR了。

DR與BDR的選舉是依靠的人為設置的路由優先順序（不設置一般默認是100），當然優先順序也能設為0，這樣這個路由器永遠不能被選舉成DR或BDR。
OSPF大致是4類網路，點到點與點到多點這兩類需要的認為指定DR/BDR，因為這兩類多用在網路分支上，方便管理。
廣播網路與NBMA這兩類則需要選舉DR/BDR。這兩類網路搭建好後，路由間會依靠一種LSA自動選舉出來DR與BDR。這兩類網路主要用於主幹網路，所以事先要謀劃計算好，輕易不能改動。過程中，如果DR壞了，BDR自動變成DR，然後又有新的BDR被選舉出來。

用命令找DR很簡單 show ip route就可以的 DR/BDR里可以看到他們與其他路由都添加鄰居，並且要復雜的多

⑦ redis主從和哨兵

主從復制：主節點負責寫數據，從節點負責讀數據，主節點定期把數據同步到從節點保證數據的一致性

a,配置主從復制方式一、新增redis6380.conf, 加入 slaveof 192.168.152.128 6379, 在6379啟動完後再啟6380，完成配置；
b,配置主從復制方式二、redis-server --slaveof 192.168.152.128 6379 臨時生效

c,查看狀態：info replication
d,斷開主從復制：在slave節點，執行6380:>slaveof no one
e,斷開後再變成主從復制：6380:> slaveof 192.168.152.128 6379
f,數據較重要的節點，主從復制時使用密碼驗證： requirepass
e, 從節點建議用只讀模式slave-read-only=yes, 若從節點修改數據，主從數據不一致
h,傳輸延遲：主從一般部署在不同機器上，復制時存在網路延時問題，redis提供repl-disable-tcp-nodelay參數決定是否關閉TCP_NODELAY,默認為關閉
參數關閉時：無論大小都會及時發布到從節點，占帶寬，適用於主從網路好的場景，
參數啟用時：主節點合並所有數據成TCP包節省帶寬，默認為40毫秒發一次，取決於內核，主從的同步延遲40毫秒，適用於網路環境復雜或帶寬緊張，如跨機房

a)一主一從：用於主節點故障轉移從節點，當主節點的「寫」命令並發高且需要持久化，可以只在從節點開啟AOF（主節點不需要），這樣即保證了數據的安全性，也避免持久化對主節點的影響

b)一主多從：針對「讀」較多的場景，「讀」由多個從節點來分擔，但節點越多，主節點同步到多節點的次數也越多，影響帶寬，也加重主節點的穩定

c)樹狀主從：一主多從的缺點（主節點推送次數多壓力大）可用些方案解決，主節點只推送一次數據到從節點B，再由從節點B推送到C，減輕主節點推送的壓力。

redis 2.8版本以上使用psync命令完成同步，過程分「全量」與「部分」復制
全量復制：一般用於初次復制場景（第一次建立SLAVE後全量）
部分復制：網路出現問題，從節點再次連接主節點時，主節點補發缺少的數據，每次數據增量同步
心跳：主從有長連接心跳，主節點默認每10S向從節點發ping命令，repl-ping-slave-period控制發送頻率

a)主從復制，若主節點出現問題，則不能提供服務，需要人工修改配置將從變主
b)主從復制主節點的寫能力單機，能力有限
c)單機節點的存儲能力也有限

a)主節點(master)故障，從節點slave-1端執行 slaveof no one後變成新主節點；
b)其它的節點成為新主節點的從節點，並從新節點復制數據；
c)需要人工干預，無法實現高可用。

1. 為什麼要有哨兵機制？

原理：當主節點出現故障時，由Redis Sentinel自動完成故障發現和轉移，並通知應用方，實現高可用性。

其實整個過程只需要一個哨兵節點來完成，首先使用Raft演算法（選舉演算法）實現選舉機制，選出一個哨兵節點來完成轉移和通知

任務1：每個哨兵節點每10秒會向主節點和從節點發送info命令獲取最拓撲結構圖，哨兵配置時只要配置對主節點的監控即可，通過向主節點發送info，獲取從節點的信息，並當有新的從節點加入時可以馬上感知到

任務2：每個哨兵節點每隔2秒會向redis數據節點的指定頻道上發送該哨兵節點對於主節點的判斷以及當前哨兵節點的信息，同時每個哨兵節點也會訂閱該頻道，來了解其它哨兵節點的信息及對主節點的判斷，其實就是通過消息publish和subscribe來完成的

任務3：每隔1秒每個哨兵會向主節點、從節點及其餘哨兵節點發送一次ping命令做一次心跳檢測，這個也是哨兵用來判斷節點是否正常的重要依據

客觀下線：當主觀下線的節點是主節點時，此時該哨兵3節點會通過指令sentinel is-masterdown-by-addr尋求其它哨兵節點對主節點的判斷，當超過quorum（選舉）個數，此時哨兵節點則認為該主節點確實有問題，這樣就客觀下線了，大部分哨兵節點都同意下線操作，也就說是客觀下線

a)每個在線的哨兵節點都可以成為領導者，當它確認（比如哨兵3）主節點下線時，會向其它哨兵發is-master-down-by-addr命令，徵求判斷並要求將自己設置為領導者，由領導者處理故障轉移；
b)當其它哨兵收到此命令時，可以同意或者拒絕它成為領導者；
c)如果哨兵3發現自己在選舉的票數大於等於num(sentinels)/2+1時，將成為領導者，如果沒有超過，繼續選舉…………

a)由Sentinel節點定期監控發現主節點是否出現了故障

sentinel會向master發送心跳PING來確認master是否存活，如果master在「一定時間范圍」內不回應PONG 或者是回復了一個錯誤消息，那麼這個sentinel會主觀地(單方面地)認為這個master已經不可用了

b) 當主節點出現故障，此時3個Sentinel節點共同選舉了Sentinel3節點為領導，負載處理主節點的故障轉移

c) 由Sentinel3領導者節點執行故障轉移，過程和主從復制一樣，但是自動執行

流程：

1. 將slave-1脫離原從節點，升級主節點，

d) 故障轉移後的redis sentinel的拓撲結構圖

a) 過濾掉不健康的（下線或斷線），沒有回復過哨兵ping響應的從節點

b) 選擇salve-priority從節點優先順序最高（redis.conf）的

c) 選擇復制偏移量最大，指復制最完整的從節點

以3個Sentinel節點、2個從節點、1個主節點為例進行安裝部署

1. 前提： 先搭好一主兩從redis的主從復制，和之前的主從復制搭建一樣，搭建方式如下：

A）主節點6379節點（/usr/local/bin/conf/redis6379.conf）：

修改 requirepass 12345678，注釋掉#bind 127.0.0.1

B) 從節點redis6380.conf和redis6381.conf: 配置都一樣

修改 requirepass 12345678 ,注釋掉#bind 127.0.0.1,

加上訪問主節點的密碼masterauth 12345678 ,加上slaveof 192.168.152.128 6379

2. redis sentinel哨兵機制核心配置 (也是3個節點)：

將三個文件的埠改成: 26379 26380 26381

然後：sentinel monitor mymaster 192.168.152.128 6379 2 //監聽主節點6379

三個配置除埠外，其它一樣。

3. 哨兵其它的配置 ：只要修改每個sentinel.conf的這段配置即可：

sentinel monitor mymaster 192.168.152.128 6379 2

//監控主節點的IP地址埠，sentinel監控的master的名字叫做mymaster，2代表，當集群中有2個sentinel認為master死了時，才能真正認為該master已經不可用了

sentinel auth-pass mymaster 12345678 //sentinel連主節點的密碼

sentinel config-epoch mymaster 2 //故障轉移時最多可以有2從節點同時對新主節點進行數據同步

sentinel leader-epoch mymaster 2

sentinel failover-timeout mymasterA **180000 **//故障轉移超時時間180s，

a,如果轉移超時失敗，下次轉移時時間為之前的2倍；

b,從節點變主節點時，從節點執行slaveof no one命令一直失敗的話，當時間超過 180S 時，則故障轉移失敗

c,從節點復制新主節點時間超過 180S 轉移失敗

sentinel down-after-milliseconds mymasterA 300000 //sentinel節點定期向主節點ping命令，當超過了 300S 時間後沒有回復，可能就認定為此主節點出現故障了……

sentinel parallel-syncs mymasterA 1 //故障轉移後， 1 代表每個從節點按順序排隊一個一個復制主節點數據，如果為3，指3個從節點同時並發復制主節點數據，不會影響阻塞，但存在網路和IO開銷

4. 啟動redis服務和sentinel服務:

a)先把之前安裝的redis裡面的標綠色的文件都拷貝到 usr/local/bin目錄下，然後再再bin目錄下新建一個conf文件夾存放配置好的redis主從配置文件和哨兵配置文件

b)啟動主從復制服務，先啟動主再啟動從

主：./redis-server conf/redis6379.conf &

從：

./redis-server conf/redis6380.conf &

./redis-server conf/redis6381.conf &

c）啟動sentinel服務:

./redis-sentinel conf/sentinel_26381.conf &

到此服務全部啟動完畢

連接到6379的redis的服務，可看到6379就是主節點，他有6380和6381兩個從節點

5. 測試： kill -9 6379 殺掉6379的redis服務

可以看到殺掉6379以後6380變為了主節點，6381變為了6380的從節點

重新啟動6379以後變為6380的從節點

看日誌是分配6380 是6381的主節點，當6379服務再啟動時，已變成從節點

假設6380升級為主節點:進入6380>info replication 可以看到role:master

打開sentinel_26379.conf等三個配置，sentinel monitor mymaster 192.168.152.128 6380 2

打開redis6379.conf等三個配置, slaveof 192.168.152.128 6380,也變成了6380

注意：生產環境建議讓redis Sentinel部署到不同的物理機上。

a，sentinel節點應部署在多台物理機（線上環境）

b，至少三個且奇數個sentinel節點

c，通過以上我們知道，3個sentinel可同時監控一個主節點或多個主節點

sentinel參考資料：
redis sentinel的機制與用法一： https://segmentfault.com/a/1190000002680804

redis sentinel的機制與用法二： https://segmentfault.com/a/1190000002685515

⑧ ES原理之選主流程

分布式系統的集群方式大致可以分為主從模式（Master-Slave）和無主模式。

常用的選舉演算法有比較簡單的Bully演算法和復雜而強大的Paxos演算法。

每個節點有一個唯一ID，然後對集群中所有的節點ID進行排序，選取其中最小的ID所屬的節點作為Master。
Bully演算法的問題： 假設當前Master因為負載過重而假死，然後ID第二大的被選舉為新的Master，這時舊的Master恢復然後又被選舉為Master然後又會因為負載過重而假死......

Paxos實現起來非常復雜,但非常強大，尤其在什麼時機,以及如何進行選舉方面的靈活性比簡單的Bully演算法有很大的優勢，因為在現實生活中，存在比網路鏈接異常更多的故障模式。
ES使用的是Bully演算法，並對其做了一些優化：

⑨ ospf選舉主從與選舉DR的聯系

兩者間沒有聯系
1，先說主從吧，所有介面網路類型都有，是決定鄰接關系建立後誰先發送update的，默認router ID 大的為主，先發update，在DBD包裡面有個欄位來選舉主從
2，DR,BDR，只在MA網路中有，用來決定是誰來做指定路由器，Dother間保持鄰居關系，只和DR為鄰接
其實，他們兩個在ospf鄰接建立過程中式發生在不同的狀態下的
我也在學習中，一起進步吧

⑩ mysql group replication單主集群jdbc怎麼配置

mysql group replication單主集群jdbc怎麼配置
主從 就是 讀寫分離，主資料庫負責寫伺服器，實時同步到從資料庫（硬體和網路不同情況會有不同時間的延遲，阿里雲主從資料庫延遲幾十毫秒）， 從資料庫負責提供讀取伺服器，創建只讀賬號 不能創建表和寫入數據。

雙主集群 沒聽過，你說的是不是Mysql的MMM架構，當一個主從掛掉了 自動切換到另外一個主從伺服器，當這個恢復後自動把增加的數據拷貝 回來 並提供服務