① mysql雙主配置-雙主帶來的管理思考
mysql雙主配置很簡單，似乎大家都只關心他的安裝和部署，大家可以用他來做雙活的方案，並沒有深刻的思考過生產環境後續管理的風險和如何銀差規避這些問題。
log-slave-updates = true
auto_increment_offset = 1 #另外一個主B是2，其他一樣。
auto_increment_increment = 2
replicate-ignore-db = mysql
replicate-ignore-db = sys
replicate-ignore-db = information_schema
replicate-ignore-db = performance_schema
replicate-ignore-db = undolog
replicate_wild_ignore_table = mysql.%
replicate_wild_ignore_table = sys.%
replicate_wild_ignore_table = information_schema.%
replicate_wild_ignore_table = performance_schema.%
replicate_wild_ignore_table = undolog.%
雙主如果一邊更新表結構，一邊在寫入，即使你認為你的的sql沒有問題。但是mysqlbinlog的寫入日誌不是這樣的，比如row格式，需要回放的日誌如下下面，你修改表結構之前是可以插入的，中間查多一列的話，你的列對不上了，導致1167錯誤。目前有兩種辦法可以規避這個鋒慶皮問題：
如差孝果忽略了一些庫，比如mysql的庫，創建賬號的時候，就需要兩邊創建。
② 什麼是MySQL集群帶你全面掌握MySQL集群原理
如果Master收橋瞎到所有 Slave的OK消息，它就會向所有Slave發送提交消息，告訴Slave提交該事務；
如果Slave收到提交請求，它們就會提交事務，並向Master發送事務已提交 的確認；
如果Slave收到取消請求,它們就會撤銷所有改變並釋放所佔有的資源，從而中止事務，然後向Masterv送敏吵空事務已中止的確認。
隨著計算機和信息技術的迅猛發展和普及，行業應用系統的規模迅速擴大，行業應用所產生的數據量量呈爆炸式增長，類似於MySQL集群這樣的技術得到了廣泛的運用，MySQL集群原理的運用就顯得尤其重要。
動力節點的MySQL集群教程 ，對於MySQL集群技術的應用場景有著詳細的介紹，能夠有效幫助我們學以致用， 教程主要從MySQL集群架構解析到架構部署再到集群架構測試，一步步帶你部署企業級的MySQL資料庫集群項目，熟悉各個環節技術點，提升資料庫架構設計能力。
https://www.bilibili.com/video/BV1Rg4y1i7VR
http://www.bjpowernode.com/?toutiao
•001.MySQL集群視頻教程：主從復制介紹
•002.MySQL集群視頻教程：主從復制結構
•003.MySQL集群視頻教程：主從復制流程原碰敗理
•004.MySQL集群視頻教程：多實例安裝
•005.MySQL集群視頻教程：多實例鏈接
•006.MySQL集群視頻教程：一主多從-配置
•007.MySQL集群視頻教程：-一主多從測試
•008.MySQL集群視頻教程：雙主雙從配置
•009.MySQL集群視頻教程：雙主雙從測試
•010.MySQL集群視頻教程：多數據源-環境搭建
•011.MySQL集群視頻教程：多算數據源實現
•012.MySQL集群視頻教程：修復MySLQ主從復制
•013.MySQL集群視頻教程：多數據源的問題
•014.MySQL集群視頻教程：動態數據源
•015.MySQL集群視頻教程：動態數據源執行流程
•016.MySQL集群視頻教程：SpringBoot集成多數據源
•017.MySQL集群視頻教程：SpringBoot集成多數據源問題
•018.MySQL集群視頻教程：SpringBoot集成動態數據源
③ 基於MySQL雙主的高可用解決方案理論及實踐
MySQL在互聯網應用中已經遍地開花，但是在銀行系統中，還在生根發芽的階段。本文記錄的是根據某生產系統實際需求，對資料庫高可用方案從需求、各高可用技術特點對比、實施、測試等過程進行整理，完善Mysql高可用方案，同時為後續開展分布式資料庫相關測試做相應准備。
存儲復制技術： 傳統IOE架構下，常用高可用方案，靠存儲底層復制技術實現數據的一致性，優點數據安全性有保障，限制在於是依賴存儲硬體，實施成本較高。
keepalived+雙主復制： 兩台MySQL互為主從關系，即雙主模式，通過Keepalived配置虛擬IP，實現當其中的一台資料庫故障時，自動切換VIP到另外一台MySQL資料庫，備機快速接管業務來保證資料庫的高可用。
MHA： MHA部署在每台mysql伺服器上，定時探測集群中的master節點，當master出現故障時，它可以自動將最新的slave提升為新的master，然後將所有其他的slave重新指向新的master，優點在最大程度保證數據的一致性的前提下實現快速切換，最少需要3台伺服器，存在數據丟失的可能性。
PXC： Percona eXtra Cluster是Percona基於galera cluster封裝的集群方案。不同於普通多主復制，PXC保障強一致性和實時同步，故障切換更快。但是也需要3個節點，配置相對復雜，對性能也稍有影響。
除了上述方案外，還有MMM、Heartbeat+DRBD等高可用方案，此處不做詳細介紹。
綜合評估下，本次實施採用了 keepalived+mysql雙主實現資料庫同城雙機房的高可用攜悶。MySQL版本為： 5.7.21。操作系統：Red Hat Enterprise Linux Server 7.3。
配置過程如下：
Mysql-master1: IP地址1 --以下簡稱master1
Mysql-master2: IP地址2 --以下簡稱master2
Mysql-vip : VIP地址 --應用連接使用
Mysql復制相關概念描述：
1、 Mysql主從復制圖示：
2、 Mysql主從復制過程描述：
（1）master記錄二進制日誌：在每個事務更新數據完成之前，master在二進制日誌記錄這些改變。MySQL將事務寫入二進制日誌。在事務寫入二進制日誌完成後，master通知存儲引擎提交事務。
（2）slave將master的binarylog拷貝到自己的中繼日誌：首先，slave開始一個工作線程——I/O線程。I/O線猛笑程在master上打開一個普通的連接，然後開始binlog mp process。Binlog mp process從master的二進制日誌中讀取事務，如果已經同步了master，它會睡眠並等待master產生新的事件。I/O線程將這些事務寫入中繼日誌。
（3）SQL slave thread處理該過程的最後一步：SQL線程從中繼日誌讀取事務，並重放其中的事務而更新slave的數據，使其與master中的數據一致。只要該線程與I/O線程保持一致，中繼日誌通常會位於OS的緩存中，所以中繼日誌的開銷很小。
主主同步就是兩台機器互為主的關系，在任何一台機器上寫入都會同步至備端。
為了便於後續資料庫伺服器的擴展，且在整個復制環境中能夠自動地切換，降低運維成本，引入了當前主流的基於Mysql GTID的復制特性，工作原理及優缺點簡介如下。
3、 GTID工作原理簡介：
（1） master更新數據時，會在事務前產生GTID，一同記錄到Binlog日誌中。
（2） slave的I/O線程將變更的辯知彎binlog寫入到本地的relay log中。
（3） slave的sql線程從relay log中獲取GTID，然後對比slave端的binlog是否有記錄。
（4） 如果有記錄說明該GTID的事務已經執行，slave會忽略。
（5） 如果沒有記錄，slave就會從relay log中執行該GTID的事務，並記錄到binlog。
（6） 在解析的過程中會判斷是否有主鍵，如果有就用索引，如果沒有就用全部掃描。
4、 GTID優點：
（1） 一個事務對應一個唯一的ID，一個GTID在一個伺服器上 只會執行一次。（2） GTID是用來替代傳統復制的方法，GTID復制與普通復制模式的最大不同就是不需要指定二進制文件名和位置。
（3） 減少手工干預和降低服務故障時間，當主機宕機之後會通過軟體從眾多的備機中提升一台備機為新的master。
5、 GTID也存在一些限制：
（1） 不支持非事務引擎。
（2） 不支持create table … select 語句復制(主庫直接報錯)。
（3） 不允許一個sql同時更新一個事務引擎表和非事務引擎表。
（4） 在一個復制組中，必須要求統一開啟GTID或者是統一關閉GTID。
（5） 開啟GTID需要重啟(5.7版本除外)。
（6） 開啟GTID後，就不再使用原理的傳統復制方式。
（7） 不支持create temporary table 和 drop temporary table語句。
（8） 不支持sql_slave_skip_counter。
前置條件：
主備兩個節點使用行內統一的安裝部署腳本安裝mysql5.7.21介質(略)
Master1端創建應用的資料庫(略)
1、 修改MySQL配置文件
參考相關配置規范，分別設置master1、master2的my.cnf文件，
其中server-id參數設置為不同值;
由於後續keepalived會掛起VIP，應用通過VIP連接資料庫，為了避免應用程序無法通過VIP訪問，需將兩個節點的bind-address參數注釋掉；
2、 設置master1端自動半同步模式
Mysql的同步模式主要有如下3種：
a. 主從同步復制：數據完整性好，但是性能消耗略高；
b. 主從非同步復制：性能消耗低，但容易出現不一致；
c. 主從半自動復制：介於上述兩種之間，既保持了數據的完整性，又提高了性能；
基於上述特性，建議採用半自動同步模式，由於後續要配置為雙主模式，因此任一節點其角色既為master又為slave，因此相關的master/slave插件要同時配置，過程如下。
（1） 首先查看庫是否支持動態載入(默認都支持)
（2） 主從庫上分別安裝插件
作為主庫，安裝插件semisync_master.so
作為從庫，安裝插件semisync_slave.so
（3） 安裝完成後，從plugin表中能夠看到剛剛安裝的插件
（4） 分別打開主從庫半同步復制
同時添加到各自的my.cnf中，在後續資料庫實例重啟時自動載入該配置。
此時查看狀態還沒有啟動
（5） 兩個節點分別啟動IO進程
（6） 查看半同步狀態
3、 將master1設為master2的主伺服器
（1）在master1主機上創建授權賬戶，允許在master2主機上連接
（2）將主庫master1數據導出
（3）將master.sql傳輸到master2上並導入
（4）在master2端將master1設置為自己的主庫，並開啟slave功能
在master2上查看slave狀態
至此master1到master2的主從復制關系已經建立完成。
4、 將master2設為master1的主伺服器
在master1上執行
在master1上查看slave狀態
1、keepalived相關概念說明：
keepalived是集群管理中保證集群高可用的一個軟體解決方案，其功能類似於heartbeat，用來防止單點故障
keepalived是以VRRP協議為實現基礎的，VRRP全稱VirtualRouter Rendancy Protocol，即虛擬路由冗餘協議。
虛擬路由冗餘協議，可以認為是實現路由器高可用的協議，即將N台提供相同功能的路由器組成一個路由器組，這個組裡面有一個master和多個backup，master上面有一個對外提供服務的vip，master會發組播（組播地址為224.0.0.18），當backup收不到vrrp包時就認為master宕掉了，這時就需要根據VRRP的優先順序來選舉一個backup當master，這樣的話就可以保證路由器的高可用了。
keepalived主要有三個模塊，分別是core 、check和vrrp。core模塊為keepalived的核心，負責主進程的啟動、維護以及全局配置文件的載入和解析。check負責 健康 檢查，包括常見的各種檢查方式。vrrp模塊是來實現VRRP協議的。同時為了避免出現腦裂，應關閉防火牆或者開啟防火牆但允許接收VRRP協議。
2、keepalived的安裝配置
（1）配置本地yum源，在master1和master2兩台伺服器上安裝keepalived的相關依賴包Kernel-devel/openssl-devel/popt-devl等
配置指向rhel-7.5.iso的yum本地源，步驟略
注意：如不知道keepalived需要哪些依賴包，可到下載後的源碼解壓目錄下查看INSTALL 文件內容，安裝需要的依賴包，源碼安裝任何一個軟體都要養成查看源碼包文檔的習慣，比如INSTALL，README,doc等文檔，可以獲得很多有用的信息。
（2）在兩台mysql上解壓縮並編譯安裝keepalived
（3）master1、master2上分別配置keepalived.conf
注意上圖紅色字體中兩個節點配置相同處及差異。
說明：keepalived只有一個配置文件keepalived.conf，裡面主要包括以下幾個配置區域：
· global_defs：主要是配置故障發生時的通知對象以及機器標識。
· vrrp_instance：用來定義對外提供服務的VIP區域及其相關屬性。
· virtual_server：虛擬伺服器定義
（4）同時兩個節點上都需要添加檢測腳本
作用：是當mysql停止工作時自動關閉本機的keeplived服務，從而實現將故障主機踢出熱備組，因每台機器上keepalived只添加了本機為realserver，所以當mysqld正常啟動後，我們還需要手動啟動keepalived服務。
（5）分別啟動兩個節點的keepalived服務
檢查兩個節點keepalived啟動進程
檢查兩個節點的vip掛載情況
（6）主備機故障切換測試
停止master2的mysql服務，看keepalived 健康 檢查程序是否會觸發腳本，自動進行故障切換，步驟略
查看master1節點的VIP掛載情況，驗證是否實現了自動切換，步驟略
說明在master2伺服器的mysql服務發生故障時，觸發了腳本，自動完成了切換。
（7）現在我們把master2的mysql服務開起來，並且keepalived的服務也需要啟動。
即便master2的mysql服務和keepalived服務都重新開啟了，master1仍然是主master了，master2未對主master的權利進行搶奪，說明設置的nopreempt參數生效了，為了保證群集的穩定性，生產環境不允許搶占配置，只有當master1的mysql服務壞掉的時候，master2才會再次成為主master，否則它永遠只能當master1的備份。（註：nopreempt一般是在優先順序高的mysql上設置）
Sysbench是一個模塊化的、跨平台、多線程基準測試工具，可用於評估資料庫負載情況，通過sysbench命令配置IP地址、埠號、用戶名、密碼連接到指定的資料庫db1中，創建多個表，並快速插入指定條數的記錄，觀察主備庫同步效率
(1) 下載開源工具sysbench-0.4.12.14.tar.gz，放置在相應目錄下並解壓
(2) 使用iso配置本地yum源並安裝Sysbench如下的依賴包(步驟略)：autoconf/automake/cdbs/debhelper(>=9)/docbook-xml/docbook-xsl/libmysqlclient15-dev/libtool/xsltproc
(3) 編譯sysbench
編輯配置文件/etc/ld.so.conf中添加mysql lib目錄/mysql/app/5.7.21/lib，並執行命令ldconfig生效
(4) 執行sysbench壓測
使用sysbench工具向主節點的db1資料庫中創建5張表，並且每張表分別插入10萬條記錄
同時觀察備機同步效率
幾個重要的參數說明：
B、半自動同步模式、非同步模式切換測試
(1) 檢查主備同步狀態，及同步參數設置
rpl_semi_sync_master_enabled參數表示啟用半同步模式；
rpl_semi_sync_master_timeout參數單位為毫秒，表示主庫事務等待從庫返回commit成功信息超過10秒就降為非同步模式，不再等待從庫，等探測到從庫io線程恢復後，再返回為半自動同步；
rpl_semi_sync_master_wait_no_slave參數表示事務提交後需要等待從庫返回確認信息；
(2) 將slave的io線程停止
(3) 使用sysbench向master寫入少量的數據，本例創建一張表，並插入10條記錄，命令包裝在1.sh測試腳本中
通過記錄的時間戳發現，master在等待了slave10秒無響應，自動切換為非同步模式，將數據寫入本地。
(4) Slave啟動io線程，數據自動追平
至此MySQL主主復制配置完成，運行在半自動同步模式，通過keepalived實現Mysql的HA高可用。
上線後應符合統一的標准監控策略，添加備份協議對數據進行周期備份並保存到帶庫中，以及定期的數據恢復測試。
由於是靠keepalived實現的高可用，還應將如下資源添加到監控管理平台：
1、 對每台資料庫主機的3個keepalived進程進行監控；
2、 對主備節點的io線程、sql線程工作狀態進行監控；
④ 容器化 | 在 KubeSphere 中部署 MySQL 集群
本文將演示如何在 KubeSphere[1] 上部署 RadonDB MySQL on Kubernetes 2.1.2 ，快速實現高可用的 MySQL on K8s。
若已在 KubeSphere 部署過歷史版本 Operator，可以選擇如下方式更新到最新版本。
可任桐敗選一個 RadonDB MySQL 配置示例[5] 部署，或自定義配置部署。
以 mysql_v1alpha1_mysqlcluster.yaml 模版為例，創建一個 RadonDB MySQL 集群。
注意
未指定項目時，集群將被默認安裝在 kubesphere-controls-system 項目中。差輪悉若需指定項目，安裝命令需添加 --namespace=<project_name> 。
預期結果
預期結果
在 demo-project 項目中，查看 RadonDB MySQL 集群狀態。
至此，完成在 KubeSphere 中部署 RadonDB MySQL 集群。
[1]：KubeSphere： https://kubesphere.com.cn
[2]：OpenPitrix： https://kubesphere.io/zh/docs/pluggable-components/app-store
[3]：創建操作： https://kubesphere.io/zh/docs/quick-start/create-workspace-and-project
[4]：項虛乎目網關： https://kubesphere.io/zh/docs/project-administration/project-gateway
[5]：配置示例： https://github.com/radondb/radondb-mysql-kubernetes/blob/main/config/samples
⑤ 兩台阿里雲伺服器，如何配置keepalived，mysql雙主
使用MySQL雙master+keepalived是一種非常好的解決方案，在MySQL-HA環境中，MySQL互為主從關系，這樣就保證了兩台MySQL數據的一致性，然後用keepalived實現虛擬IP，通過keepalived自帶的服務監控功能來實現MySQL故障時自動切換。
下面，我把即將上線的一個生產環境中的架構與大家分唯消享一下，看一下這個架構中，MySQL-HA是如何實現的，環境拓撲如下
MySQL-VIP：散團10.10.10.21
MySQL-master1：10.10.10.17
MySQL-master2：10.10.10.18
OS版本：Redhat6.2
MySQL版本：mysql-5.1.59
Keepalived版本：keepalived-1.1.20
一、MySQL master-master配置
1、修改MySQL配置文件
兩台MySQL均如要開啟binlog日誌功能，開啟方法：在MySQL配置文件[MySQLd]段中加上log-bin=MySQL-bin選項
兩台MySQL的server-ID不能一樣，默認情況下兩台MySQL的serverID都是1，需將其中一台修改為2即可
Master1配置：
#vim /etc/my.cnf
log-bin=mysql-bin //開啟binlog日誌功能
log =/usr/local/mysql/var/mysql.log //會列印mysql的所以sql語句
server-id= 1 //
binlog-do-db =mysql //需要同步的庫名稱
auto-increment-increment= 2
auto-increment-offset= 2
Master2配置：
#vim /etc/my.cnf
log-bin=mysql-bin //開啟binlog日誌功能
log =/usr/local/mysql/var/mysql.log //會列印mysql的所以sql語句
server-id= 2
binlog-do-db =mysql //需要同步的庫名稱
auto-increment-increment= 2
auto-increment-offset= 2
2、建沖山橘授權用戶
在10.10.10.17上新建授權用戶
grant replicationslave on *.* to test@』10.10.10.%』 identified by 『123456』;
在10.10.10.18伺服器上建授權用戶
grant replicationslave on *.* to test@』10.10.10.%』 identified by 『123456』;
3、將10.10.10.17設為10.10.10.18的主伺服器
在10.10.10.18上將10.10.10.17設為自己的主伺服器
mysql> show master status;（17伺服器配置）
1+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000027| 106|mysql | |
+------------------+----------+--------------+------------------+
1 row in set (0.01 sec)
MySQL> change master to master_host='10.10.10.17',master_user=』test』,master_password='123456',master_log_file='MySQL-bin.000027',master_log_pos=106;
Query OK, 0 rows affected (0.05 sec)
MySQL> start slave;
Query OK, 0 rows affected (0.00 sec)
mysql> show slave status \G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes \\如果此2項都為yes，master-master配置即成功
將10.10.10.18設為10.10.10.17的主伺服器 方法與上面設置一致只需將
在10.10.10.17上將10.10.10.18設為自己的主伺服器
mysql> show master status;（18伺服器配置）
1+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000027| 106|mysql | |
+------------------+----------+--------------+------------------+
1 row in set (0.01 sec)
MySQL> change master to master_host='10.10.10.18',master_user=』test』,master_password='123456',master_log_file='MySQL-bin.000027',master_log_pos=106;
Query OK, 0 rows affected (0.05 sec)
MySQL> start slave;
Query OK, 0 rows affected (0.00 sec)
mysql> show slave status \G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes \\如果此2項都為yes，master-master配置即成功
測試是否成功：
如上述均正確配置，現在在任何一台MySQL上更新數據都會同步到另一台MySQL(僅限mysql庫)
二、keepalived安裝及配置
1、10.10.10.17伺服器上keepalived安裝及配置
安裝keepalived
#tar zxvfkeepalived-1.1.20.tar.gz
#cdkeepalived-1.1.20
#./configure--prefix=/usr/local/keepalived--with-kernel-dir=/usr/src/kernels/2.6.32-220.el6.x86_64
#make &&make install
配置keepalived
我們自己在新建一個配置文件，默認情況下keepalived啟動時會去/etc/keepalived目錄下找配置文件
#mkdir/etc/keepalived
#vi/etc/keepalived/keepalived.conf
global_defs {
notification_email {
}
smtp_server 127.0.0.1 （如果本機配置的話）
smtp_connect_timeout 30
router_id MySQL-ha
}
vrrp_instance VI_1{
state BACKUP #兩台配置此處均是BACKUP
interface p4p1 #注意網卡介面
virtual_router_id 51
priority 100 #優先順序，另一台改為90
advert_int 1
nopreempt #不主動搶占資源，只在優先順序高的機器上設置即可，優先順序低的機器不設置
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
10.10.10.21
}
}
virtual_server10.10.10.21 3306 {
delay_loop 2 #每個2秒檢查一次real_server狀態
lb_algo wrr #LVS演算法
lb_kind DR #LVS模式
persistence_timeout 60 #會話保持時間
protocol TCP
real_server 10.10.10.17 3306 {
weight 3
notify_down /usr/local/my/my.sh #檢測到服務down後執行的腳本
TCP_CHECK {
connect_timeout 10 #連接超時時間
nb_get_retry 3 #重連次數
delay_before_retry 3 #重連間隔時間
connect_port 3306 #健康檢查埠
}
}
編寫檢測服務down後所要執行的腳本
#vi/usr/local/MySQL/bin/MySQL.sh
#!/bin/sh
pkillkeepalived
#chmod +x/usr/local/MySQL/bin/MySQL.sh
註：此腳本是上面配置文件notify_down選項所用到的，keepalived使用notify_down選項來檢查real_server的服務狀態，當發現real_server服務故障時，便觸發此腳本；我們可以看到，腳本就一個命令，通過pkill keepalived強制殺死keepalived進程，從而實現了MySQL故障自動轉移。另外，我們不用擔心兩個MySQL會同時提供數據更新操作，因為每台MySQL上的keepalived的配置裡面只有本機MySQL的IP+VIP，而不是兩台MySQL的IP+VIP
啟動keepalived
#/usr/local/keepalived/sbin/keepalived–D
#ps -aux | grepkeepalived
測試
找一台區域網PC，然後去ping MySQL的VIP，這時候MySQL的VIP是可以ping的通的
停止MySQL服務，看keepalived健康檢查程序是否會觸發我們編寫的腳本
1、10.10.10.18伺服器上keepalived安裝及配置
安裝keepalived
#tar zxvfkeepalived-1.1.20.tar.gz
#cdkeepalived-1.1.20
#./configure--prefix=/usr/local/keepalived--with-kernel-dir=/usr/src/kernels/2.6.32-220.el6.x86_64
#make &&make install
配置keepalived
我們自己在新建一個配置文件，默認情況下keepalived啟動時會去/etc/keepalived目錄下找配置文件
#mkdir/etc/keepalived
#vi/etc/keepalived/keepalived.conf
global_defs {
notification_email {
}
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id MySQL-ha
}
vrrp_instance VI_1{
state BACKUP #兩台配置此處均是BACKUP
interface p4p1 #注意網卡介面
virtual_router_id 51
priority 90 #優先順序，另一台改為90
advert_int 1
authentication {
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
10.10.10.21
}
}
virtual_server10.10.10.21 3306 {
delay_loop 2 #每個2秒檢查一次real_server狀態
lb_algo wrr #LVS演算法
lb_kind DR #LVS模式
persistence_timeout 60 #會話保持時間
protocol TCP
real_server 10.10.10.18 3306 {
weight 3
notify_down /usr/local/my/my.sh #檢測到服務down後執行的腳本
TCP_CHECK {
connect_timeout 10 #連接超時時間
nb_get_retry 3 #重連次數
delay_before_retry 3 #重連間隔時間
connect_port 3306 #健康檢查埠
}
}
啟動keepalived
#/usr/local/keepalived/sbin/keepalived–D
#ps -aux | grepkeepalived
測試
停止MySQL服務，看keepalived健康檢查程序是否會觸發我們編寫的腳本
三、測試
兩台MySQL伺服器都要授權允許從遠程登錄
MySQL> grantall privileges on *.* to andyguo@'%' identified by '123456';
Query OK, 0 rowsaffected (0.00 sec)
MySQL> flushprivileges;
Query OK, 0 rowsaffected (0.00 sec)
keepalived故障轉移測試:
在windows客戶端一直去ping VIP，然後關閉10.10.10.17上的keepalived，正常情況下VIP就會切換到10.10.10.18上面去
開啟10.10.10.17上的keepalived，關閉10.10.10.18上的keepalived，看是否能自動切換，正常情況下VIP又會屬於10.10.10.17
註：keepalived切換速度還是非常塊的，整個切換過程只需1-3秒
MySQL故障轉移測試：
在10.10.10.17上關閉MySQL服務，看VIP是否會切換到10.10.10.18上
開啟10.10.10.17上的MySQL和keepalived，然後關閉10.10.10.18上的MySQL，看VIP是否會切換到10.10.10.17上
如果都沒問題，到此整個配置即已完成。
備注（在測試的過程中遇到了一些問題，解決方法）
Keepalived_healthcheckers:IPVS: Can't initialize ipvs: Protocol not available
起初重裝了ipvsadm和keepalived，但故障依舊，隨後突然想到是否lvs模塊載入異常，於是lsmod|grep ip_vs發現果然沒有相應的模塊，而正常情況下應該是有的
e、手動載入ip_vs模塊
modprobe ip_vs
modprobe ip_vs_wrr
f、重啟keepalived服務，故障排除，此時轉發正常，從伺服器的ip_vs載入正常，主從切換也正常
g、將modprobeip_vs、modprobe ip_vs_wrr添加進/etc/rc.local開機自動載入
⑥ Mysql的雙主模式
Keepalived是基於VRRP（Virtual Router Rendancy Protocol，皮判虛擬路由器冗餘協議）協議的一款高可用軟體。Keepailived有一台主伺服器（master）和多台備份伺服器（backup），在主伺服器和備份伺服器上面部署相同的服務配置，使用一個虛擬IP地址雀談對外提供服務，當主伺服器出現故障時，虛擬IP地址會自動漂移到備份伺服器。
1.有一個錯誤：
2020-12-08T17:24:00.656737Z 9 [ERROR] Slave I/O for channel '': Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work. Error_code: 1593
解決辦法，修改其中一台伺服器的server-uuid，並保證server-uuid的格式正確，修改完成之後重啟Mysql服務就可以了。
在修改配置文件之前，先登錄Mysql客戶端查看uuid，把返回的頃握碰uuid復制，放到要修改的配置文件即可。
⑦ jdbc框架項目如何配置 mysql雙主 目前項目中配置的數據源是在tomcat中
方法/步驟
打開tomcat目錄，進入conf配置目錄，有個context.xml文件，一般建議把數據源配置放在這個文件里進行配置，放在server.xml也是可以的，但不建議這么做，server.xml文件一般是tomcat服務相關的配置
