mysql主從同步與讀寫分離

為了解決數據庫服務的高可用問題以及負載均衡問題，

1正常情況下可以互為主從，均衡分擔數據流量，

2防止數據庫服務器在宕機的情況下可以順利切換到正常的數據庫服務器，減少公司的客戶流量損失故公司需要搭建數據庫集群以備不時之需。

一主一從

首先准備兩台已安裝好數據庫的服務器：分別為A為主服務器和B從服務器

第一步初始化數據庫：

1，備份A數據庫服務器中所有的數據

[root@es1 ~]#mysql -uroot -p

mysql> reset master    #重置binlog日志

mysql> quit           　　#退出數據庫

[root@es1 ~]# mysqldump -uroot -p --all-databases >/root/test.sql

[root@es1 ~]# ls         #查看備份結果

2在從庫B中導入備份的數據

登錄B服務器

[root@es2 ~]#mysql -uroot -p

mysql>drop database text；        　　# 清除所有測試數據

[root@es1 ~]# scp /root/mytest.sql root@192.168.12.118:/root/   #將數據庫A中備份的數據上傳至B數據庫
root@192.168.12.118's password:
mytest.sql 100% 790 418.8KB/s 00:00

mysql -u root -p < /mytest.sql  將數據備份至B數據庫，

第二步配置主從數據庫

在AB數據庫服務器數據一致，binlog還原點一致的情況下進行配置

1：配置主服務器，修改/etc/my.cnf

[root@es1 ~]# vim /etc/my.cnf

[client]
default-character-set=utf8

[mysqld]

character-set-server=utf8
validate_password_policy=0
validate_password_length=6

log-bin=mysql1-bin
server_id=1
binlog_format=MIXED

[root@es1 ~]# systemctl restart mysqld　　#重啟數據庫

2：新建一個用戶授予器復制權限允許其從從服務器slave訪問

mysql> grant select replication slave on *.* to 'replicater'@'192.168.12.%' identified by 'pwd123';

mysql> show master status\G  #查看主服務器狀態 

注意 ：當在授予權限時出現密碼安全問題時

ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

這個就是初始設置密碼策略的問題：先查看密碼策略

mysql> show variables like 'validate_password%';

解決方案：

mysql> set global validate_password_mixed_case_count=2;  

關於 mysql 密碼策略相關參數；
1）、validate_password_length  固定密碼的總長度；
2）、validate_password_dictionary_file 指定密碼驗證的文件路徑；
3）、validate_password_mixed_case_count  整個密碼中至少要包含大/小寫字母的總個數；
4）、validate_password_number_count  整個密碼中至少要包含阿拉伯數字的個數；
5）、validate_password_policy 指定密碼的強度驗證等級，默認為 MEDIUM；
關於 validate_password_policy 的取值：
0/LOW：只驗證長度；
1/MEDIUM：驗證長度、數字、大小寫、特殊字符；
2/STRONG：驗證長度、數字、大小寫、特殊字符、字典文件；
6）、validate_password_special_char_count 整個密碼中至少要包含特殊字符的個數；

 

3 配置從服務器

vi /etc/my.cnf

[client]

[client]
default-character-set=utf8   #設置數據庫客戶端編碼utf8

[mysqld]

character-set-server=utf8     #設置服務端編碼utf8
validate_password_policy=0    #密碼策略密碼復雜度
validate_password_length=6　　#密碼長度

log-bin=mysql2-bin            #bin-log日志前綴
server_id=2　　　　　　　　　　　　#數據庫服務器主機id
binlog_format=MIXED　　　　　　#日志格式

[root@es2 ~]# systemctl restart mysqld

[root@es2 ~]# mysql -uroot -p

mysql> change master to master_host='192.168.12.119',  　　 #指定主服務器的ip地址
    ->  master_user='replicater', 　　　　　　　　　　　　　　　#指定主庫授權用戶用戶名
    ->  master_password='12345678',　　　　　　　　　　　　 　　#授權用戶密碼
    ->  master_log_file='mysql1-bin.0000001',　　　　　　　　#主庫bin-log日志
    ->  master_log_pos=123;　　　　　　　　　　　　　　　　　　　#指定備份節點
Query OK, 0 rows affected, 2 warnings (0.01 sec)

mysql> START SLAVE; //啟動復制

[root@es2 ~]# ls -lh /var/lib/mysql/        注 ：master.info  ，MASTER 主服務器的設置信息自動存為 master.info 文件

mysql> show slave status\G

無論是一主一從，一主多從，互為主從，其原理都是從庫指定主庫

注意點，就是主從庫必須要一致才能同步，否則會受中繼日志和bin-log日志中的pos點的影響而無法同步，配置主從同步時4關閉防火牆。

 在配置主從同步可能遇到的問題

 報錯一

Last_IO_Errno: 2003

Last_IO_Error: error connecting to master 'coolcloud@XXXX:XX' - retry-time: 60  retries: 86400

 這個就是防火牆的問題了，關閉防火牆即可

systemctl stop firewalld         關閉防火牆

systemctl disable firewalld     開機不啟動防火牆

 再重新指定主庫

報錯二

Last_IO_Errno: 1236                 

Last_IO_Error: Got fatal error 1236 from master when reading dat

 這個問題時因為從庫在指定主庫配置的時候   master_log_pos=123;　#指定pos節點錯誤導致需查看

解決方案是：

查看主庫中的狀態
mysql> show master status\G 

在從庫中

mysql>stop slave

change master to master_host='192.168.12.119',
 master_user='replicater',
 master_password='pwd123',
 master_log_file='mysql1-bin.000006', # 需重新根據主庫指定 master_log_pos=154;  # 需重根據主庫新指定

再啟動 

 mysql>start slave

 三：總結（更多報錯）

1、須在主、從服務器配置文件 /etc/my.cnf指定
server_id (任意，建議指定不易混淆，有規律，有邏輯的)
binlog日志（一般不指定時日志名稱默認為主機名-bin.00000x）
binlog-format="mixed" （指定日志格式，一般為混合格式“mixed”，根據需求而定）
注意： 如果以上沒有指定，都會報錯錯；
2、在主庫上面授權：允許用戶對主庫有復制權限 （replication：復制）
grant replication slave on . to 用戶名@"服務器地址" identified by "密碼";
必須要授權（從庫無法指定主庫並復制）
3指定組服務器：（缺一不可）
登錄數據庫
change master to master_host="主服務器地址"
master_user=“主庫上的授權用戶“
master_password="授權賬戶密碼“
master_log_file= " 主服務器binlog日志名稱“
master_log_pos=”binlog日志偏移量”
最后啟動主從復制start slave
查看重服務器狀態
Slave_IO_Running: （負責與主機的io通信）
Slave_SQL_Running: （負責自己的slave 數據庫進程）
如果不出問題的話，主從同步就部署成功了，

但是這世界並不太平，如果IO線程啟動失敗
以下是我遇到的問題：
1、主服務器的防火牆沒關，導致從服務器同步失敗
解決方案：關閉防火牆；
2、主從服務器數據庫中數據不一致，（部署主從服務時）
先將不同的部分備份到對方的數據庫中保證數據的一致
（不建議刪庫刪庫刪表）
3、binlog日志偏移量不對，從服務器找不到同步節點
打開主服務器binlog日志文件，找到數據偏移量，重新指定就可以了。
如果是SQL線程啟動失敗：
我碰到的情況如下：
1、Last_SQL_Error: Error 'Operation DROP USER failed for 'yy'@'192.168.4.10'' on query. Default database: 'alldb'. Query: 'drop user yy@192.168.4.10'
就是沒有同步之前的的主庫授權用戶，在部署完之后發現從庫上沒有之前主庫上的授權用戶，然后我撤銷了，從庫的SQL線程就斷了，所以要謹慎操作。
解決辦法：一般都不是刪除、撤銷、當然就是在從庫上做同樣的授權。
2、Slave failed to initialize relay log info structure from the repository
當出現這種報錯時：一般原因是默認中繼日志relay_log被服務器上另一個mysql slave占用了；
解決方案：

　　1、初始化中繼日志， 即刪除relay-log.info中繼日志文件
　　2、在配置文件/etc/my.cnf 中指定中繼日志名稱
　　3、當配置高可用集群時，SQL線程啟動失敗報錯如下
3、Master command COM_REGISTER_SLAVE failed: Access denied for user 'monitor'@'%' (using password: YES) (Errno: 1045)
當出現這種報錯時：
　　1主服務器的級聯復制功能未開啟
解決方案：在配置文件中log_slave_updates # 允許級聯復制，重起服務，還有是主庫必須添加授權用戶。
　　2還有就是刪除授權用戶，（不建議）。
綜上所述：部署主從同步時對數據庫服務器具有高度的統一性。

第三步 使用keepalived實現數據庫集群的故障切換功能，實現數據庫的高可用

1下載安裝keepalived 

安裝依賴  yum install -y pcre-devel openssl-devel popt-devel

 [root@es1 ~]# wget https://www.keepalived.org/software/keepalived-2.0.15.tar.gz

 [root@es1 ~]# tar -axvf  keepalived-2.0.15.tar.gz

 [root@es1 ~]# cd  keepalived-2.0.15

[root@es1 keepalived-2.0.15]# ./configure  --prefix=/opt/keepalived

[root@es1 keepalived-2.0.15]#make  && make install

[root@es1 keepalived-2.0.15]#systemctl start keepalived 

報錯如下

journalctl -xe 查看具體原因   如圖因為未找到keepalived配置文件導致

 

解決方案

[root@es1 ~]# cp -r /opt/keepalived/etc/keepalived /etc/

2keepalived配置：

keepalived配置手冊：https://www.keepalived.org/manpage.html

 cat keepalived.conf  #注意主從均需安裝配置keepalived  

vrrp_script chk_mysql_port {     #檢測mysql服務是否在運行。有很多方式，比如進程，用腳本檢測等等
    script "/opt/chk_mysql.sh"   #這里通過腳本監測
    interval 2                   #腳本執行間隔，每2s檢測一次
    weight -5                    #腳本結果導致的優先級變更，檢測失敗（腳本返回非0）則優先級 -5
    fall 2                    #檢測連續2次失敗才算確定是真失敗。會用weight減少優先級（1-255之間）
    rise 1                    #檢測1次成功就算成功。但不修改優先級
}
vrrp_instance VI_1 {
    state MASTER
    interface ens33 #指定虛擬ip的網卡接口,不一定是eth0根據ifconfig確定
    virtual_router_id 51 #路由器標識，MASTER和BACKUP必須是一致的
    priority 100 #定義優先級，數字越大，優先級越高，在同一個vrrp_instance下，MASTER的優先級必須大於BACKUP的優先級。這樣MASTER故障恢復后，就可以將VIP資源再次搶回來
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 123456
    }
    virtual_ipaddress {
        192.168.11.25
    }
    track_script {
       chk_mysql_port
    }
}

編寫監控腳本

cat /opt/chk_mysql.sh

#!/bin/bash
counter=$(netstat -na|grep "LISTEN"|grep "3306"|wc -l)
if [ "${counter}" -eq 0 ]
then
    /etc/init.d/keepalived stop
else
   echo "running..." >> /opt/keepalived-running-info.log
   sleep 5000
fi

啟動keepalived服務

 systemctl start keepalived

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2017-12-30 18:51:10