2. 程式人生 > >MySQL主從復制Replication

MySQL主從復制Replication

阿新 • • 發佈：2019-03-08
延時 mas show 地址 節點 data form you only

技術分享圖片

主從復制原理

1、主從復制的前提
1.1 兩臺以上mysql實例
多臺物理機
多個mysql實例
1.2 主庫要開啟二進制日誌

1.3 主庫要提供復制相關的用戶
replication slave，一個比較特殊的權限
grant replication slave on . to repl@‘10.0.0.%‘ identified by ‘123‘;
1.4 從庫需要將和主庫相差的數據，進行追加
一般情況下可以人為備份主庫數據，恢復到從庫上
1.5 從應該從恢復之後的時間點，開始自動從主庫獲取新的二進制日誌開始應用
我們需要人為告訴從庫，從哪開始自動開始復制二進制日誌(file+position)，另外還需要告訴從庫user,passwd,port,ip

change master to

2、復制中的線程及文件
2.1、主庫
Dump（IO） thread：在復制過程中，主庫發送二進制日誌的線程
2.2、從庫
IO thread：向主庫請求二進制日誌，並且接受二進制日誌的線程
SQL thread：執行請求過來的二進制的線程
2.3、主庫
binlog文件：主庫的二進制日誌
2.4、從庫
relaylog:中繼日誌，存儲請求過來的二進制日誌
master.info:
1、從庫連接主庫的重要參數（user,passwd,ip,port）
2、上次獲取過的主庫二進制日誌的位置
relay-log.info
存儲從庫SQL線程已經執行過的relaylog日誌位置

3、主從復制的工作原理

3.1 從庫，IO線程，讀取master.info中的信息，
    獲取到連接參數（user\passwd\ip\port）+上次請求過的主庫的binlog的位置(例子：mysql-bin.000003，position=640)
3.2 IO線程使用鏈接到主庫，拿著位置信息（mysql-bin.000003，position=640），問主庫有沒有比這個更新的二進制日誌。
3.3 主庫查詢二進制日誌，並對比從庫發送過來的位置信息（mysql-bin.000003，position=640），如果有新的二進制日誌，會通過
    dump thread發送給從庫。
3.4 從庫通過IO線程，接受主庫發來的二進制日誌，存儲到TCP/IP緩存中，並且返回“ACK”確認給主庫，這時主庫收到ACK後，
    就認為復制完成了，可以繼續其他工作了。
3.5 從庫更新master.info，二進制日誌位置更新為新的位置信息。
3.6 從庫IO線程會將TCP/IP緩存中的日誌，存儲到relay-log中繼日誌文件中。
3.7 從庫SQL線程，讀取relay-log.info,獲取到上次執行到的relaylog日誌位置，以這個位置信息作為起點，往後繼續執行中繼日誌。
3.8 SQL線程執行完成所有relay之後，會更新relay-log.info信息為新位置信息。

到此為止，一次完整的復制過程就完成了。

主從復制搭建

1、準備環境
思路：
1、兩個以上節點（多實例）

3307：master
3308：slave1
3309：slave2

2、主庫binlog開啟，從庫開啟relay-log（默認在數據目錄下生成）
vim /data/3307/my.cnf

log-bin=/data/3307/mysql-bin
binlog_format=row

3、server-id不同

[root@db02 data]# cat /data/3307/my.cnf |grep server-id
server-id=3307
[root@db02 data]# cat /data/3308/my.cnf |grep server-id
server-id=3308
[root@db02 data]# cat /data/3309/my.cnf |grep server-id
server-id=3309

4、關閉數據庫的自動域名解析
每個節點都加入以下配置：
skip-name-resolve
5、啟動多實例

mysqld_safe --defaults-file=/data/3307/my.cnf &
mysqld_safe --defaults-file=/data/3308/my.cnf &
mysqld_safe --defaults-file=/data/3309/my.cnf &

6、主庫創建復制賬戶
連接到主庫：

mysql -S /data/3307/mysql.sock
grant replication slave on *.* to repl@‘10.0.0.%‘ identified by ‘123‘;

7、從庫數據的追加
（1）不需要追加的情況
主和從同時搭建的新環境，就不需要備份主庫數據，恢復到從庫了，直接從第一個binlog（mysql-bin.000001）的開頭位置（120）
（2）如果主庫已經工作了很長時間了，我們一般需要備份主庫數據，恢復到從庫，然後從庫從備份的時間點起自動進行復制

重點針對第二種情況進行演示：
備份主庫：

mysqldump -S /data/3307/mysql.sock -A -R  --triggers --master-data=2 --single-transaction >/tmp/full.sql
sed -n ‘22p‘ /tmp/full.sql 
-- CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.000002‘, MASTER_LOG_POS=325

恢復到從庫：

mysql -S /data/3308/mysql.sock 
mysql> set sql_log_bin=0;
mysql> source /tmp/full.sql

8、從庫開啟主庫：

mysql -S /data/3308/mysql.sock

help change master to

CHANGE MASTER TO
  MASTER_HOST=‘10.0.0.52‘,
  MASTER_USER=‘repl‘,
  MASTER_PASSWORD=‘123‘,
  MASTER_PORT=3307,
  MASTER_LOG_FILE=‘mysql-bin.000002‘,
  MASTER_LOG_POS=325;

開啟主從（開啟IO和SQL線程）：
start slave;

9、查看主從狀態：

show slave status\G

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

10、主從重要狀態信息介紹

show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_IO_Errno: 0
Last_IO_Error: 
Last_SQL_Errno: 0
Last_SQL_Error:

IO線程故障：

1、主庫連接不上
user、password、port、ip 錯誤
解決方案：

        stop  slave;    
        reset slave all;  
        change master to    
        start slave;
   防火墻
   網絡不通
     skip-name-resolve
       stop  slave;
       start slave;

2、主庫二進制日誌丟失或損壞
解決方案：

        stop  slave;    
        reset slave all;

重新備份恢復

        change master to    
        start slave;

SQL線程故障：
執行relaylog日誌新事件
1、刪除、修改對象的操作時，沒有這個對象
2、創建對象時，對象已存在
3、主鍵沖突
從庫做寫入操作，會導致以上問題出現

處理方法：

stop slave; 
set global sql_slave_skip_counter = 1; 
start slave;

/etc/my.cnf
slave-skip-errors = 1032,1062,1007

但是，以上操作有時是有風險的，最安全的做法就是重新構建主從。

怎麽預防以上問題？

從庫加入配置文件

set global read_only=1;
vim /etc/my.cnf
read_only=1           ---->只能控制普通用戶

11、主從異常——主從延時過長

show slave status \G
Seconds_Behind_Master:0

默認的主從復制機制是異步的一個過程。

主庫原因:
1、主庫做修改操作之後，才會記錄二進制日誌。
sync_binlog=0/1

If the value of this variable is greater than 0, 
the MySQL server synchronizes its binary log to disk (using fdatasync()) 
after sync_binlog commit groups are written to the binary log. 
The default value of sync_binlog is 0, which does no synchronizing to disk—in this case,
the server relies on the operating system to flush the binary log‘s contents from time to time as for any other file. 
A value of 1 is the safest choice because in the event of a crash you lose at most one commit group from the binary log. 
However, it is also the slowest choice (unless the disk has a battery-backed cache, which makes synchronization very fast)
 1：表示：每次事務commit，刷新binlog到磁盤
 0：系統決定binlog什時候刷新到磁盤

2、主庫的壓力特別大（大事務、多事務）
3、從庫數量多，導致dump線程繁忙

從庫原因：

1、relay-log寫入慢
2、SQL線程慢（主從硬件差異比較大）

盡可能的避免主從延時

1、sync_binlog=1
2、大事務拆成小事務，多事務進行分離
3、使用多級主從，分庫分表架構
4、將binlog放到ssd或者flash上，高性能存儲
5、將relay放到ssd或者flash上
6、盡量選擇和主庫一致硬件和配置

12、主從復制高級功能——半同步復制

出發點：保證主從數據一致性的問題，安全的考慮

5.5 出現的概念，但是不建議使用，性能太差

5.6以後出現group commit 組提交功能，來提升開啟版同步復制的性能

5.7 增強半同步復制的新特性：after sync;
加載插件

主:
INSTALL PLUGIN rpl_semi_sync_master SONAME ‘semisync_master.so‘;

從:
INSTALL PLUGIN rpl_semi_sync_slave SONAME ‘semisync_slave.so‘;

查看是否加載成功:
show plugins;

啟動:
主:
SET GLOBAL rpl_semi_sync_master_enabled = 1;

從:
SET GLOBAL rpl_semi_sync_slave_enabled = 1;

重啟從庫上的IO線程
STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;

查看是否在運行
主:
show status like ‘Rpl_semi_sync_master_status‘;
從:
show status like ‘Rpl_semi_sync_slave_status‘;

補充：
rpl_semi_sync_master_timeout | 10000
默認情況先,到達10秒鐘還沒有ack，主從關系自動切換為普通復制
如果是1主多從的半同步復制，只要有一臺落地relaylog，返回ack，這次半同步就完成了。

13、主從復制高級功能——延時從庫

會專門找一個節點，配置成延時節點，盡可能防止邏輯損壞，一般情況下這個節點會被用備份

我們配置的是SQL_thread的延時

mysql>stop slave;

mysql>CHANGE MASTER TO MASTER_DELAY = 60;

mysql>start slave;

mysql> show slave status \G
SQL_Delay: 300

取消延時：

mysql> stop slave;
mysql> CHANGE MASTER TO MASTER_DELAY = 0;
mysql> start slave;

14、主從復制高級功能——復制過濾

主庫方面控制（不建議使用）：
白名單:只記錄白名單中列出的庫的二進制日誌
binlog-do-db
黑名單：不記錄黑名單列出的庫的二進制日誌
binlog-ignore-db

從庫方面控制：
白名單：只執行白名單中列出的庫或者表的中繼日誌 

--replicate-do-db=test
--replicate-do-table=test.t1
--replicate-wild-do-table=test.x*

黑名單：不執行黑名單中列出的庫或者表的中繼日誌

--replicate-ignore-db
--replicate-ignore-table
--replicate-wild-ignore-table

15、主從復制新特性——GTID復制

GTID，5.6新特性
GTID(Global Transaction ID)是對於一個已提交事務的編號，並且是一個全局唯一的編號。
它的官方定義如下：
GTID = source_id ：transaction_id
7E11FA47-31CA-19E1-9E56-C43AA21293967:29

每一臺mysql實例中，都會有一個唯一的uuid，標識實例的唯一性
auto.cnf，存放在數據目錄下

重要參數：

gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
gtid-mode=on                                        --啟用gtid類型，否則就是普通的復制架構
enforce-gtid-consistency=true       --強制GTID的一致性
log-slave-updates=1                         --slave更新是否記入日誌

構建1主2從的GTID復制環境：

3臺虛擬機，
db02 克隆兩臺虛擬機環境，分別命名為db01、db03，在生產中準備3臺真實的物理機，不用多實例

要求：

1、IP地址、主機名
db01:10.0.0.51/24
db03:10.0.0.53/24
2、清理所有之前3306的相關數據，只留軟件

db01:

cd /application/mysql/data/
\rm -rf *
cd /data/binlog/
\rm -rf *

db02:

cd /application/mysql/data/
\rm -rf *
cd /data/binlog/
\rm -rf *

db03:

cd /application/mysql/data/
\rm -rf *
cd /data/binlog/
\rm -rf *

3、準備配置文件
規劃：

    主庫： 10.0.0.51/24
    從庫1: 10.0.0.52/24
    從庫2：10.0.0.53/24

主庫：
加入以下配置信息

db01:10.0.0.51/24

vim /etc/my.cnf

[mysqld]
basedir=/application/mysql
datadir=/application/mysql/data
socket=/tmp/mysql.sock
log-error=/var/log/mysql.log
log_bin=/data/binlog/mysql-bin
binlog_format=row
skip-name-resolve
server-id=51
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[client]
socket=/tmp/mysql.sock

slave1：
db02:10.0.0.52/24

vim /etc/my.cnf

[mysqld]
basedir=/application/mysql
datadir=/application/mysql/data
socket=/tmp/mysql.sock
log-error=/var/log/mysql.log
log_bin=/data/binlog/mysql-bin
binlog_format=row
skip-name-resolve
server-id=52
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[client]
socket=/tmp/mysql.sock

slave2：
db02:10.0.0.53/24

vim /etc/my.cnf

[mysqld]
basedir=/application/mysql
datadir=/application/mysql/data
socket=/tmp/mysql.sock
log-error=/var/log/mysql.log
log_bin=/data/binlog/mysql-bin
binlog_format=row
skip-name-resolve
server-id=53
gtid-mode=on
enforce-gtid-consistency=true
log-slave-updates=1
[client]
socket=/tmp/mysql.sock

三臺節點分別初始化數據：

/application/mysql/scripts/mysql_install_db --user=mysql  --basedir=/application/mysql --datadir=/application/mysql/data/ 

分別啟動三個節點mysql：

/etc/init.d/mysqld start

測試啟動情況：
mysql -e "show variables like ‘server_id‘"

master:51 slave:52,53

51:
grant replication slave  on *.* to repl@‘10.0.0.%‘ identified by ‘123‘;
52\53:

change master to master_host=‘10.0.0.51‘,master_user=‘repl‘,master_password=‘123‘ ,MASTER_AUTO_POSITION=1;

start slave;

MySQL主從復制Replication

相關推薦

MySQL主從復制Replication

延時 mas show 地址 節點 data form you only 主從復制原理 1、主從復制的前提1.1 兩臺以上mysql實例多臺物理機多個mysql實例1.2 主庫要開啟二進制日誌 1.3 主庫要提供復制相關的用戶replication slave，一個比較特

mysql主從復制

值變化 -- stat 可能 inf 地址 base 數據 waiting 1、主從服務器分別作以下操作： 1.1、版本一致 1.2、初始化表，並在後臺啟動mysql 1.3、修改root的密碼2、修改主服務器master: #vi /etc/my.cnf

MySQL主從復制原理深入解析與練習

數據庫 記錄 sql語句 change master MySQL主從復制原理深入解析與練習MySQL主從復制畫圖描述：MySQL主從復制原理上圖詳解：①　用戶做crud操作，寫入數據庫，更新結果記錄到binlog中；②　主從同步是主找從的，從庫IO發起請求，主庫的主進程看從庫的master

mysql 主從復制配置

安裝 connect 生成 for ica www cte 數據庫服務 grant 二、MySQL主從復制場景描述：主數據庫服務器：192.168.10.130，MySQL已經安裝，並且無應用數據。從數據庫服務器：192.168.10.131，MySQL已經安裝，並且無

MySQL 主從復制擴展

blog height spa 擴展 html htm mysql 主從 bin 策略 (1) 主庫的線程狀態 (2) 從庫的線程狀態 (3) MySQL 主從復制備份策略 (4) MySQL 主從復制延遲問題 (5) 讓從庫記錄 binlog 日誌

Mysql 主從復制 及 一些要註意的特殊設置

數據庫 配置文件 主從復制 主從模式 0.準備A.安裝數據庫： 主從mysql數據庫 （mysql server）都安裝好：版本上，mysql 允許 低版本master 配 高版本slavehttps://dev.mysql.com/doc/refman/5.7/en/replication-

2-16 mysql主從復制

完整 version tab arc pos binlog data red community 2-16 mysql主從復制 1. 部署MYSQL主從同步 <M-S> 環境：mysql版本一致，均為5.7.18 master xuegod4

mysql主從復制讀寫分離

mysql主從 mysql讀寫分離 mysql主從復制讀寫分離一、MYSQL讀寫分離的概述Mysql作為目前世界上使用最廣泛的免費數據庫，相信所有從事系統運維的工程師都一定接觸過。但在實際的生產環境中，由單臺Mysql作為獨立的數據庫是完全不能滿足實際需求的，無論是在安全性，高可用性以及高並發等各個方

Ansible 管理MySQL主從復制

unit class border moni 必須 aml conn scala body mysql_replication - 管理MySQL復制 1.3版新功能 概要 要求（在執行模塊的主機上） 選項 例子 筆記 狀態 支持 概要 管理MySQL

mysql主從復制配置

服務 ssh auto mysqld 實時數據 配置 均衡 t_sql ges 同步原理： 同步時從庫由兩個線程完成（IO,SQL），主庫由一個線程完成（IO）； 要把主庫的數據先還原到從庫，主庫備份的點就是從庫change master的點，或者使用參數--master

MySQL主從復制（一）

mysql mysql主從 web一般是拒絕用戶上傳的，webdav可以實現數據上傳MySQL的擴展方式：scale up：scale out：一、MySQL的擴展：復制：每個node都有相同的數據集從node請求主node的二進制日誌，在本地進行重放實現復制的作用：數據分布：負載均衡：//讀均衡，寫

MySQL主從復制Galera

主從復制 galera cluster 多線程復制 gtid 一、主從復制的問題和解決方案二、Galera Cluster三、MySQL 5.6的多線程復制、GTID MySQL Replication： Master HA或多主節點模型 MMM：multi master MySQL M

MySQL主從復制與讀寫分離

$0 get 登錄 nice ica oca kcon 過程 ads 主從復制(Master-Slave)與讀寫分離(Mysql作為目前世界上使用最廣泛的免費數據庫，相信所有從事系統運維的工程師都一定接觸過。但在實際的生產環境中，由單臺主從復制（Master-Slave）

mysql主從復制實戰——詳細

mysqlmysql主從原理：1）至少需要2臺數據庫服務器，一主一從，master開啟bin-log功能。（bin-log功能用戶記錄主控增 加、刪除、修改、更新SQL的語句。) 2)異步復制的過程，有延遲，毫秒級別（延遲和你的網絡和性能、數據庫的量級有關），開啟3個線程。分別是maste

zabbix監控mysql主從復制

zabbix監控mysql主從復制 zabbix mysql5.6zabbix監控mysql主從復制.監控MySQL的復制原理：利用在slave上運行show slave status獲取Slave_IO_Running和Slave_SQL_Running的值1.在mysql上新建監控用戶 grant r

MySQL主從復制的實現過程

36-6 備份 出現 傳輸 size 無法 con 行數據 排版 一、什麽是主從復制 將主數據庫中的DDL和DML操作通過二進制日誌（BINLOG）傳輸到從數據庫上，然後將這些日誌重新執行（重做）；從而使得從數據庫的數據與主數據庫保持一致。 二、主從復制的作用 1、主數據庫

MySQL主從復制技術與讀寫分離技術amoeba應用

buffer chan lns -a query rep 下載 高可用性 tab MySQL主從復制技術與讀寫分離技術amoeba應用 前言：眼下在搭建一個人才站點，估計流量會非常大，須要用到分布式數據庫技術，MySQL的主從復制+讀寫分

Linux下MySQL主從復制（二）

mysql 鄰居 MySQL的一主多從模式原理結構圖配置步驟1.主服務器： 1. 改變server id 2. 啟用二進制日誌文件 3. 創建具有復制的用戶123123具體操作請看：http://www.crazyrui.pw:8088/index.php/2017/07/23/linux_m

mysql 主從復制原理

mysql:主從主從形式mysql主從復制 靈活一主一從主主復制一主多從---擴展系統讀取的性能，因為讀是在從庫讀取的；多主一從---5.7開始支持聯級復制--- 用途及條件 mysql主從復制用途實時災備，用於故障切換讀寫分離，提供查詢服務備份，避免影響業務 主從部署必要條件：主庫開啟binlog日誌（設置

mysql主從復制跳過錯誤

ren class 結果 test mysql gin ack table .cn mysql主從復制，經常會遇到錯誤而導致slave端復制中斷，這個時候一般就需要人工幹預，跳過錯誤才能繼續跳過錯誤有兩種方式：1.跳過指定數量的事務：mysql>slave stop;