Mysql數據庫實現高可用
阿新 • • 發佈：2018-02-25
ide 接下來 自動 內容 eth1 code 源碼安裝 網絡 ole
Mysql實現高可用
MMM
MMM（master-master replication manager for mysql）mysql主主復制管理器。 MMM是一套靈活的腳本程序，基於perl實現，用來對mysql replication進行監控和故障遷移，並能管理mysql master-master復制的配置（同一時間只有一個節點是可寫的）。 MMM的監管端是會提供多個虛擬ip（vip），包括一個可寫的vip，多個可讀的vip，通過監管的管理，這些ip會綁定在可用的mysql上，當某一臺mysql宕機時，會將vip遷移到其他mysql。 mmm_mond：監控進程，負責所有的監控工作，決定和處理所有節點角色活動。因此，腳本需要在監管上運行。 mmm_agentd：運行在每個msql服務器上的代理進程，完成監控的探針工作和執行簡單的遠端服務設置。此腳本需要在被監管機上運行。 mmm_control：一個簡單的腳本，提供管理mmm_mond進行的命令。 MMM實現mysql高可用 MMM（Master-Master replication manager for MySQL）是一套支持雙主故障切換和雙主日常管理的腳本程序。 MMM使用Perl語言開發，主要用來監控和管理MySQL Master-Master（雙主）復制，雖然叫做雙主復制，但是業務上同一時刻只允許對一個主進行寫入，另一臺備選主上提供部分讀服務，以加速在主主切換時刻備選主的預熱，可以說MMM這套腳本程序一方面實現了故障切換的功能，另一方面其內部附加的工具腳本也可以實現多個slave的read負載均衡。 MMM提供了自動和手動兩種方式移除一組服務器中復制延遲較高的服務器的虛擬ip，同時它還可以備份數據，實現兩節點之間的數據同步等。 由於MMM無法完全的保證數據一致性，所以MMM適用於對數據的一致性要求不是很高，但是又想最大程度的保證業務可用性的場景。 對於那些對數據的一致性要求很高的業務，非常不建議采用MMM這種高可用架構。 MMM項目來自 Google：http://code.google.com/p/mysql-master-master 官方網站為：http://mysql-mmm.org 下面我們通過一個實際案例來充分了解MMM的內部架構，如下圖所示。 具體的配置信息如下所示： 角色 ip地址 主機名字 server-id monitoring 192.168.0.30 db2 - master1 192.168.0.60 db1 1 master2 192.168.0.50 db2 2 slave1 192.168.0.40 db3 3 業務中的服務ip信息如下所示： ip地址 角色 描述 192.168.0.108 write 應用程序連接該ip對主庫進行寫請求 192.168.0.88 read 應用程序連接該ip進行讀請求 192.168.0.98 read 應用程序連接該ip進行讀請求 具體的配置步驟如下： （1）主機配置 配置/etc/hosts,在所有主機中，添加所有的主機信息： [[email protected] ~]# cat /etc/hosts 192.168.0.60 db1 192.168.0.50 db2 192.168.0.40 db3 [[email protected] ~]# （2）首先在3臺主機上安裝mysql和搭建復制（192.168.0.60和192.168.0.50互為主從，192.168.0.40為192.168.0.60的從）具體的復制搭建這裏就省略，然後在每個mysql的配置文件中加入以下內容，註意server_id 不能重復。 db1（192.168.0.60）上： server-id = 1 log_slave_updates = 1 auto-increment-increment = 2 auto-increment-offset = 1 db2（192.168.0.50）上： server-id = 2 log_slave_updates = 1 auto-increment-increment = 2 auto-increment-offset = 2 db3（192.168.0.40）上： server-id = 3 log_slave_updates = 1 上面的id不一定要按順序來，只要沒有重復即可。 （3）安裝MMM所需要的Perl模塊（所有服務器）執行該腳本，也可以安裝epel源，然後yum -y install mysql-mmm*來安裝MMM： rpm -ivh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm yum -y install mysql-mmm* [[email protected] ~]# cat install.sh #!/bin/bash wget http://xrl.us/cpanm --no-check-certificate mv cpanm /usr/bin chmod 755 /usr/bin/cpanm cat > /root/list << EOF install Algorithm::Diff install Class::Singleton install DBI install DBD::mysql install File::Basename install File::stat install File::Temp install Log::Dispatch install Log::Log4perl install Mail::Send install Net::ARP install Net::Ping install Proc::Daemon install Thread::Queue install Time::HiRes EOF for package in `cat /root/list` do cpanm $package done [[email protected] ~]# （4）下載mysql-mmm軟件，在所有服務器上安裝： [[email protected] ~]# wget http://mysql-mmm.org/_media/:mmm2:mysql-mmm-2.2.1.tar.gz [[email protected] ~]# mv :mmm2:mysql-mmm-2.2.1.tar.gz mysql-mmm-2.2.1.tar.gz [[email protected] ~]# tar xf mysql-mmm-2.2.1.tar.gz [[email protected] ~]# cd mysql-mmm-2.2.1 [[email protected] mysql-mmm-2.2.1]# make install mysql-mmm安裝後的主要拓撲結構如下所示（註意：yum安裝的和源碼安裝的路徑有所區別）： 目錄 介紹 /usr/lib/perl5/vendor_perl/5.8.8/MMM MMM使用的主要perl模塊 /usr/lib/mysql-mmm MMM使用的主要腳本 /usr/sbin MMM使用的主要命令的路徑 /etc/init.d/ MMM的agent和monitor啟動服務的目錄 /etc/mysql-mmm MMM配置文件的路徑，默認所以的配置文件位於該目錄下 /var/log/mysql-mmm 默認的MMM保存日誌的位置 到這裏已經完成了MMM的基本需求，接下來需要配置具體的配置文件，其中mmm_common.conf，mmm_agent.conf為agent端的配置文件，mmm_mon.conf為monitor端的配置文件。 （5）配置agent端的配置文件，需要在db1，db2，db3上分別配置。 在db1主機上配置agent配置文件： [[email protected] ~]# cd /etc/mysql-mmm/ [[email protected] mysql-mmm]# cat mmm_common.conf active_master_role writer <host default> cluster_interface eth1 pid_path /var/run/mmm_agentd.pid bin_path /usr/lib/mysql-mmm/ replication_user repl replication_password 123456 agent_user mmm_agent agent_password mmm_agent </host> <host db1> ip 192.168.0.60 mode master peer db2 </host> <host db2> ip 192.168.0.50 mode master peer db1 </host> <host db3> ip 192.168.0.40 mode slave </host> <role writer> hosts db1, db2 ips 192.168.0.108 mode exclusive </role> <role reader> hosts db2, db3 ips 192.168.0.88, 192.168.0.98 mode balanced </role> [[email protected] mysql-mmm]# 其中replication_user用於檢查復制的用戶，agent_user為agent的用戶，mode標明是否為主或者備選主，或者從庫。mode exclusive主為獨占模式，同一時刻只能有一個主，<role write>中hosts表示目前的主庫和備選主的真實主機ip或者主機名，ips為對外提供的虛擬機ip地址，<role readr>中hosts代表從庫真實的ip和主機名，ips代表從庫的虛擬ip地址。 由於db2和db3兩臺主機也要配置agent配置文件，我們直接把mmm_common.conf從db1拷貝到db2和db3兩臺主機的/etc/mysql-mmm下。 註意：monitor主機要需要： scp /etc/mysql-mmm/mmm_common.conf db2:/etc/mysql-mmm/ scp /etc/mysql-mmm/mmm_common.conf db3:/etc/mysql-mmm/ 分別在db1，db2，db3三臺主機的/etc/mysql-mmm配置mmm_agent.conf文件，分別用不同的字符標識，註意這三臺機器的this db1這塊要想，比如本環境中，db1要配置this db1，db2要配置為this db2，而db3要配置為this db3。 在db1（192.168.0.60）上： [[email protected] ~]# cat /etc/mysql-mmm/mmm_agent.conf include mmm_common.conf this db1 [[email protected] ~]# 在db2（192.168.0.50）上： [[email protected] ~]# cat /etc/mysql-mmm/mmm_agent.conf include mmm_common.conf this db2 [[email protected] ~]# 在db3（192.168.0.40）上： [[email protected] ~]# cat /etc/mysql-mmm/mmm_agent.conf include mmm_common.conf this db3 [[email protected] ~]# 在db2（192.168.0.30）配置monitor的配置文件： [[email protected] ~]# cat /etc/mysql-mmm/mmm_mon.conf include mmm_common.conf <monitor> ip 127.0.0.1 pid_path /var/run/mysql-mmm/mmm_mond.pid bin_path /usr/libexec/mysql-mmm status_path /var/lib/mysql-mmm/mmm_mond.status ping_ips 192.168.0.40,192.168.0.50,192.168.0.60 auto_set_online 60 </monitor> <host default> monitor_user mmm_monitor monitor_password mmm_monitor </host> debug 0 [[email protected] ~]# 這裏只在原有配置文件中的ping_ips添加了整個架構被監控主機的ip地址，而在<host default>中配置了用於監控的用戶。 （6）創建監控用戶，這裏需要創建3個監控用戶，具體描述如下： 用戶名 描述 權限 monitor user MMM的monitor端監控所有的mysql數據庫的狀態用戶 REPLICATION CLIENT agent user 主要是MMM客戶端用於改變的master的read_only狀態用戶 SUPER,REPLICATION CLIENT,PROCESS repl 用於復制的用戶 REPLICATION SLAVE 在3臺服務器(db1,db2,db3）進行授權，因為我之前的主主復制，以及主從已經是ok的，所以我在其中一臺服務器執行就ok了。用於復制的賬號之前已經有了，所以這裏就授權兩個賬號。 mysql> GRANT SUPER, REPLICATION CLIENT, PROCESS ON *.* TO ‘mmm_agent‘@‘192.168.0.%‘ IDENTIFIED BY ‘mmm_agent‘; Query OK, 0 rows affected (0.08 sec) mysql> GRANT REPLICATION CLIENT ON *.* TO ‘mmm_monitor‘@‘192.168.0.%‘ IDENTIFIED BY ‘mmm_monitor‘; Query OK, 0 rows affected (0.00 sec) mysql> flush privileges; Query OK, 0 rows affected (0.03 sec) mysql> 如果是從頭到尾從新搭建，則加上另外一個復制賬戶（分別在3臺服務器都需要執行這3條SQL）： GRANT REPLICATION SLAVE ON *.* TO ‘repl‘@‘192.168.0.%‘ IDENTIFIED BY ‘123456‘; （7）啟動agent服務。 最後分別在db1，db2，db3上啟動agent，並在db2（192.168.0.30）上啟動monitor程序： [[email protected] ~]# /etc/init.d/mysql-mmm-agent start Daemon bin: ‘/usr/sbin/mmm_agentd‘ Daemon pid: ‘/var/run/mmm_agentd.pid‘ Starting MMM Agent daemon... Ok [[email protected] ~]# [[email protected] ~]# /etc/init.d/mysql-mmm-agent start Starting MMM Agent Daemon: [ OK ] [[email protected] ~]# 因為我有些使用yum安裝的，所以啟動信息有些不一樣。^_^ [[email protected] ~]# /etc/init.d/mysql-mmm-agent start Starting MMM Agent Daemon: [ OK ] [[email protected] ~]# 啟動monitor： [[email protected] ~]# /etc/init.d/mysql-mmm-monitor start Starting MMM Monitor Daemon: [ OK ] [[email protected] ~]# 其中agent的日誌存放在/var/log/mysql-mmm/mmm_agentd.log，monitor日誌放在/var/log/mysql-mmm/mmm_mond.log，啟動過程中有什麽問題，通常日誌都會有詳細的記錄。 （8）在monitor主機上檢查集群主機的狀態： [[email protected] ~]# mmm_control checks all db2 ping [last change: 2014/04/18 00:29:01] OK db2 mysql [last change: 2014/04/18 00:29:01] OK db2 rep_threads [last change: 2014/04/18 00:29:01] OK db2 rep_backlog [last change: 2014/04/18 00:29:01] OK: Backlog is null db3 ping [last change: 2014/04/18 00:29:01] OK db3 mysql [last change: 2014/04/18 00:29:01] OK db3 rep_threads [last change: 2014/04/18 00:29:01] OK db3 rep_backlog [last change: 2014/04/18 00:29:01] OK: Backlog is null db1 ping [last change: 2014/04/18 00:29:01] OK db1 mysql [last change: 2014/04/18 00:29:01] OK db1 rep_threads [last change: 2014/04/18 00:29:01] OK db1 rep_backlog [last change: 2014/04/18 00:29:01] OK: Backlog is null [[email protected] ~]# （9)在monitor主機上檢查集群環境在線狀況： [[email protected] ~]# mmm_control show db1(192.168.0.60) master/ONLINE. Roles: writer(192.168.0.108) db2(192.168.0.50) master/ONLINE. Roles: reader(192.168.0.88) db3(192.168.0.40) slave/ONLINE. Roles: reader(192.168.0.98) [[email protected] ~]# （10）online（上線）所有主機： 我這裏主機已經在線了，如果沒有在線，可以使用下面的命令將相關主機online [[email protected] ~]# mmm_control set_online db1 OK: This host is already ONLINE. Skipping command. [[email protected] ~]# 提示主機已經在線，已經跳過命令執行了。 到這裏整個集群就配置完成了。從輸出中可以看到虛擬ip 192.168.0.108已經順利添加到主機192.168.0.60上作為主對外提供寫服務，虛擬ip 192.168.0.88添加到主機192.168.0.50上對外提供讀服務，而虛擬ip 192.168.0.98添加到192.168.0.40上對外提供讀服務。 MMM高可用測試 我們已經完成高可用環境的搭建了，下面我們就可以做MMM的HA測試咯。首先查看整個集群的狀態，可以看到整個集群狀態正常。 [[email protected] ~]# mmm_control show db1(192.168.0.60) master/ONLINE. Roles: writer(192.168.0.108) db2(192.168.0.50) master/ONLINE. Roles: reader(192.168.0.88) db3(192.168.0.40) slave/ONLINE. Roles: reader(192.168.0.98) [[email protected] ~]# 模擬db2（192.168.0.50 ）宕機，手動停止mysql服務，觀察monitor日誌： [[email protected] ~]# tail -f /var/log/mysql-mmm/mmm_mond.log 2014/04/18 00:55:53 FATAL State of host ‘db2‘ changed from ONLINE to HARD_OFFLINE (ping: OK, mysql: not OK) 從日誌發現db2的狀態有ONLINE轉換為HARD_OFFLINE 重新查看集群的最新狀態： [[email protected] ~]# mmm_control show db1(192.168.0.60) master/ONLINE. Roles: writer(192.168.0.108) db2(192.168.0.50) master/HARD_OFFLINE. Roles: db3(192.168.0.40) slave/ONLINE. Roles: reader(192.168.0.88), reader(192.168.0.98) [[email protected] ~]# 重啟db2，可以看到db2由HARD_OFFLINE轉到AWAITING_RECOVERY。這裏db2再次接管讀請求。 [[email protected] ~]# mmm_control show db1(192.168.0.60) master/ONLINE. Roles: writer(192.168.0.108) db2(192.168.0.50) master/ONLINE. Roles: reader(192.168.0.88) db3(192.168.0.40) slave/ONLINE. Roles: reader(192.168.0.98) [[email protected] ~]# 模擬db1主庫宕機： 查看集群狀態： [[email protected] ~]# mmm_control show db1(192.168.0.60) master/HARD_OFFLINE. Roles: db2(192.168.0.50) master/ONLINE. Roles: reader(192.168.0.88), writer(192.168.0.108) db3(192.168.0.40) slave/ONLINE. Roles: reader(192.168.0.98) [[email protected] ~]# 查看MMM日誌： [[email protected] ~]# tail -f /var/log/mysql-mmm/mmm_mond.log 2014/04/18 01:09:20 FATAL State of host ‘db1‘ changed from ONLINE to HARD_OFFLINE (ping: OK, mysql: not OK) 從上面可以發現，db1由以前的ONLINE轉化為HARD_OFFLINE，移除了寫角色，因為db2是備選主，所以接管了寫角色，db3指向新的主庫db2，應該說db3實際上找到了db2的sql現在的位置，即db2 show master返回的值，然後直接在db3上change master to到db2。 db1，db2，db3之間為一主兩從的復制關系，一旦發生db2，db3延時於db1時，這個時刻db1 mysql宕機，db3將會等待數據追上db1後，再重新指向新的主db2，進行change master to db2操作，在db1宕機的過程中，一旦db2落後於db1，這時發生切換，db2變成了可寫狀態，數據的一致性將會無法保證。 總結： MMM不適用於對數據一致性要求很高的環境。但是高可用完全做到了。 參考資料： http://mysql-mmm.org/mmm2:guide
MHA
MHA是一款開源的MySQL高可用程序，MHA在監控到master節點故障時，會自動提升其中擁有最新數據的slave節點成為新的master節點。 在此期間，MHA會獲取其他節點的額外信息來避免一致性方面的問題，也就是MHA會獲取其他從節點中的數據信息，並將信息發給最接近主節點的從節點，這樣主節點故障時會提升此從節點為主節點，而此從節點擁有其他從節點所有的數據信息。 MHA還提供了master節點的在線切換功能，即按需切換master/slave節點。 實現master HA 環境 A:192.168.213.251,node1，MHA B:192.168.213.252,node2，主 C:192.168.213.253,node3，從 D:192.168.213.254,node4，從 1》同步各節點的時間。 2》可以修改/etc/hosts文件，使各節點能使用主機名交互 192.168.213.251 node1 192.168.213.252 node2 192.168.213.253 node3 192.168.213.254 node4 3》使各節點能基於ssh秘鑰的驗證 在node1節點上操作 ssh-keygen ##生成公鑰私鑰對 ssh-copy-id node1: ##將秘鑰文件保存在自己的家目錄下，會自動保存到root家目錄的.ssh目錄中 [root@node1 ~]# ls .ssh ##可以發現公鑰 和私鑰對及秘鑰文件都已經生成 authorized_keys id_rsa id_rsa.pub known_hosts scp -r .ssh/ node2: scp -r .ssh/ node3: scp -r .ssh/ node4: ##將此目錄傳給其他節點，這樣各節點就可以基於key的驗證互相通訊了 註意：基於ssh的key的驗證和能夠互相解析主機名是此實驗的前提 4》搭建好主從復制的集群環境，並確保復制運行無錯誤 在node2上的配置 vim /etc/my.cnf.d/server.cnf ##開啟二進制日誌和中繼日誌 [server] skip_name_resolve = on innodb_file_per_table = on max_connections = 20000 log_bin = bin-log server_id = 1 relay-log = relay-log 在node3和node4上的配置 vim /etc/my.cnf.d/server.cnf [server] skip_name_resolve = on innodb_file_per_table = on max_connections = 20000 relay-log = relay-log server_id = 2 ##id號必須唯一 log-bin = bin-log relay_log_purge = 0 ##不修剪中繼日誌 read_only = 1 ##只讀 5》在主從節點上授權一個用戶，用於MHA連接到各主從節點進行管理及各主從節點間通訊用 在node2上操作，創建後其他從節點也會有這個用戶 MariaDB [(none)]> grant all on *.* to mhaadmin@‘192.168.213.%‘ identified by ‘centos‘; MariaDB [(none)]> flush privileges; 註意：這裏授權的用戶不是只給MHA使用，其他的主從節點也要使用這個用戶進行互相連接通訊，所以授權的時候要保證IP地址段對所有節點都能通過這個賬號連接彼此 6》下載MHA軟件包並安裝 在https://github.com/官方網站上下載，搜索的時候輸入mha 或者到如下網站上去下載 https://code.google.com/p/mysql-master-ha/wiki/Downloads?tm=2。 mha4mysql-manager-0.56-0.el6.noarch.rpm mha4mysql-node-0.56-0.el6.noarch.rpm 在node1節點上安裝mha4mysql-manager-0.56-0.el6.noarch.rpm和mha4mysql-node-0.56-0.el6.noarch.rpm兩個軟件包 註意：安裝mha4mysql-manager-0.56-0.el6.noarch.rpm時會依賴會多的包，所以yum安裝之前要把自己的yum倉庫配置如下 root@node1 ~]# vim /etc/yum.repos.d/aliyun.repo [aliyun] name=aliyun baseurl=https://mirrors.aliyun.com/epel/7/x86_64/ gpgcheck=0 安裝之前要把網絡配置好，保證node1節點能訪問互聯網 在其他node2、node3、node4節點上只安裝mha4mysql-node-0.56-0.el6.noarch.rpm包即可 7》初始化MHA mkdir /etc/masterha ##創建一個配置文件 cd /etc/masterha vim test.cnf [server default] user=mhaadmin ##用戶MHA和各節點互相通訊的管理用戶 password=centos manager_workdir=/data/masterha/test ##MHA的工作目錄 manager_log=/data/masterha/test/manager.log ##MHA的日誌目錄 remote_workdir=/data/masterha/test ##各節點的工作目錄 ssh_user=root ##ssh連接的用戶，因為基於key的驗證了，所以不用密碼 repl_user=repluser ##主從復制時的用戶 repl_password=rpluser ping_interval=1 ##MHA監控各節點的時間間隔 [server1] hostname=192.168.213.252 candidate_master=1 ##是否可以做為候選，也就是主節點掛了，是否可以提升為主節點 [server2] hostname=192.168.213.253 candidate_master=1 [server3] hostname=192.168.213.254 candidate_master=1 8》檢查各節點ssh互相通訊 masterha_check_ssh --conf=/etc/masterha/app1.cnf All SSH connection tests passed successfully. 檢查管理的mysql復制集群的連接配置參數 masterha_check_repl --conf=/etc/masterha/app1.cnf MySQL Replication Health is OK. 9》測試 在node1上啟動MHA，並關閉node2節點的mariadb服務進行測試 masterha_manager --conf=/etc/masterha/test.cnf ##發現啟動MHA後為前臺運行的 在node2節點上關閉服務 systemctl stop mariadb 在node4上查看 MariaDB [(none)]> show slave status \G ##發現node3變成了主，切換成功 在node1節點上 masterha_manager --conf=/etc/masterha/test.cnf MySQL Replication Health is NOT OK! ##發現主從復制集群已經not ok 10》如何恢復node2？將node2變為node3的從 在node2上進行如下配置 vim /etc/my.cnf.d/server.cnf [server] skip_name_resolve = on innodb_file_per_table = on max_connections = 20000 log_bin = bin-log server_id = 1 relay-log = relay-log relay_log_purge = 0 ##不修剪中繼日誌 read_only = on ##只讀，修改這兩項就可以 將node2變為node3的從 [root@node2 ~]#mysql MariaDB [(none)]> change master to master_user=‘rpluser‘,master_host=‘192.168.213.253‘,master_password=‘1234‘,master_log_file=‘bin-log.000003‘,master_log_pos=245; ##將自己變成node3的從，如果node2修復時間很長，恢復為從的時候要先將主上的數據進行一次全量備份，在node2上恢復後再進行恢復為從的操作，保證不丟失數據 MariaDB [(none)]> start slave; MariaDB [(none)]> show slave status \G 在node1上檢查 masterha_check_repl --conf=/etc/masterha/test.cnf ---發現ok了 這樣我們又可以啟動監控了，為了保證監控時在後臺執行，並且記錄在日誌中可以進行如下操作 [root@node1 masterha]# nohup masterha_manager --conf=/etc/masterha/test.cnf &> /data/masterha/app1/manager.log & 故障轉移完成後，manager將會自動停止，此時使用masterha_check_status --conf=/etc/masterha/test.cnf 命令將會遇到錯誤提示 test is stopped(2:NOT_RUNNING). masterha_stop --conf=/etc/masterha/test.cnf ##停止MHA
Mysql數據庫實現高可用