大佬教程收集整理的这篇文章主要介绍了从理论到实战，彻底搞懂MySQL主从复制原理，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
复制的基本问题是解决不同服务器的数据保持同步c;一台主库的数据可以同步到多台备库上c;备库本身也可以被配置为另外一台服务器的主库c;主库和备库之间可以有多种不同的组合方式。
在实战前c;先理解主从复制的原理更为重要。主从复制过程中有三个线程c;主库有一个工作线程 I/O dump threadc;备库有两个工作线程c;I/O thread 和 SQL thread
在 MySQL5.0 以前只支持基于语句的复制。基于语句的复制模式下c;主库会记录那些造成数据更改的操作c;当备库读取并重放这些操作时c;实际上只是把主库上的SQL执行一遍。好处是实现简单c;简单的记录并执行这些语句c;能让主备保持同步。
但实际上基于语句的复制方式有时会出问题。因为主库上的数据更新除了执行的语句外c;可能还依赖于其他因素c;例如c;同一条 SQL 在主库和备库上的执行时间可能稍有不同c;因此在传输带 binlog 中c;还包括一些元数据信息c;如当前的时间戳c;还存在着一些无法被正确复制的 SQLc;例如c;CURRENT_USER() 函数的语句。存储过程和触发器在使用基于语句的复制模式时也可能存在问题。
也有一些情况c;基于行复制的代价会比较大c;例如： update tb_user set age=10;
由于这条 SQL 会更新全表c;使用基于行的开销会很大c;因为每一行的数据都会记录到 binlog 中c;这使得 binlog 文件庞大c;并且会给主库增加额外的负载。
以上两种模式的混合使用c;一般的复制使用 STATEMENT 模式保存 binlogc;对于 STATEMENT 模式无法复制的操作使用 ROW 模式保存 binlogc;R_864_11845@ySQL 会根据执行的 SQL 语句选择日志保存方式。
因为两种模式各有优缺点以及使用的场合c;所以 MySQL 支持在这两种复制模式中动态切换（MIXED模式）c;R_864_11845@ySQL8.0 默认使用基于行复制的方式c;理论上基于行的复制模式在整体上更优c;且在实际应用中适用于大多数场景。c;当然也可以使用参数 binlog_format 手动指定复制的模式。
本文操作实战环境：MySQL 8.0.26 + centos7
1、两台服务器分别部署 MySQLc;两台服务器 ip 为：
2、在 my.cnf 中设置 server_id：
注：更改 server_id 后需重启服务
3、开启 GTID 模式
在主库 my.cnf 中配置如下参数：
gitd_mode=on
enforce_gtid_consistency=on
log_bin=on
备库中要配置：
gitd_mode=on
enforce_gtid_consistency=on
log_slave_updates=1
4、检查主库是否开启了 log_bin 参数（MySQL8.0默认开启）
@H_965_132@mysql> show variables like '%log_bin%'; +---------------------------------+-----------------------------+ | Variable_name | Value | +---------------------------------+-----------------------------+ | log_bin | ON | | log_bin_basename | /var/lib/@H_367_183@mysql/binlog | | log_bin_index | /var/lib/@H_367_183@mysql/binlog.index | | log_bin_trust_function_creators | OFF | | log_bin_use_v1_row_events | OFF | | sql_log_bin | ON | +---------------------------------+-----------------------------+ 6 rows in set (0.01 sec)
5、将 binlog 格式设置为基于行复制的格式（MySQL8.0 默认为 ROW）
@H_965_132@mysql> show variables like '%binlog_format%'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | binlog_format | ROW | +---------------+-------+ 1 row in set (0.00 sec)
6、创建主从复制账号
# 账号：bak;密码：123456;在 96 段可用
mysql> create user 'bak'@'192.168.96.%' identified by '123456';
Query OK, 0 rows affected (0.04 sec)
mysql> grant Replication slave on *.* to 'bak'@'192.168.96.%';
Query OK, 0 rows affected (0.00 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
7、主库上查询状态
@H_965_132@mysql> show master status; +---------------+----------+--------------+------------------+-------------------------------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +---------------+----------+--------------+------------------+-------------------------------------------+ | binlog.000003 | 908 | | | 62cd056a-e9f1-11eb-9218-0242ac110002:1-16 | +---------------+----------+--------------+------------------+-------------------------------------------+ 1 row in set (0.00 sec)
8、在备库上配置主从
@H_965_132@mysql>change master to MASTER_HOST='192.168.96.95',@H_367_183@mASTER_USER='bak',@H_367_183@mASTER_password='123456',@H_367_183@mASTER_LOG_FILE='binlog.000003',@H_367_183@mASTER_LOG_POS=908; Query OK, 0 rows affected, 8 warnings (0.03 sec)
其中c;参数如下：
其中c;R_864_11845@ASTER_LOG_FILE 和 MASTER_LOG_POS 参数可以指定为当前 主库中的 binlog 文件的 posc;可以先做主库的全量备份c;再从主库中指定的 binlog 的 pos 开始同步。
9、备库上开启主从同步
@H_965_132@mysql> start slave; Query OK, 0 rows affected, 1 warning (0.00 sec)
10、查看备库状态
@H_965_132@mysql> show slave statusG *************************** 1. row *************************** Slave_IO_State: WaiTing for source to send event Master_Host: 192.168.96.95 Master_User: root Master_Port: 3306 Connect_Retry: 60 Master_Log_File: binlog.000004 Read_Master_Log_Pos: 2898 Relay_Log_File: 0981bb088bd0-relay-bin.000002 Relay_Log_Pos: 1093 Relay_Master_Log_File: binlog.000004 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 0 Last_Error: Skip_Counter: 0 Exec_Master_Log_Pos: 2898 Relay_Log_Space: 1309 Until_Condition: None Until_Log_File: Until_Log_Pos: 0 Master_SSL_Allowed: No Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: 0 Master_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 0 Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id: 10000 Master_UUID: 62cd056a-e9f1-11eb-9218-0242ac110002 Master_Info_File: mysql.slave_master_info SQL_Delay: 0 SQL_Remaining_Delay: NULL Slave_SQL_Running_State: Replica has read all relay log; waiTing for more updates Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_timestamp: Last_SQL_Error_timestamp: Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 62cd056a-e9f1-11eb-9218-0242ac110002:32 Executed_Gtid_Set: 267c5d14-e9f4-11eb-a424-0242ac110002:1-12, 62cd056a-e9f1-11eb-9218-0242ac110002:32 Auto_Position: 0 Replicate_Rewrite_DB: ChAnnel_Name: Master_TLS_Version: Master_public_key_path: Get_master_public_key: 0 Network_Namespace: 1 row in set, 1 warning (0.00 sec)
其中c;一些重要的参数：
Slave_IO_Running 和 Slave_SQL_Running 两个参数都为 yes 时c;代表从节点配置正确。
11、验证主从同步
在主库中执行 insert 语句c;可以看到备库中成功完成了同步。
主库中 user 表记录：
12、slave 设置为 read-only
@H_965_132@mysql> show variables like '%read_only%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | innodb_read_only | OFF | | read_only | OFF | | super_read_only | OFF | | transaction_read_only | OFF | +-----------------------+-------+ 4 rows in set (0.01 sec) mysql> set global read_only=1; Query OK, 0 rows affected (0.00 sec)
一主一从的架构模式下c;一般备库用来读c;建议在从服务商启动 read-only 选项c;这样保证从服务器上的数据仅与主服务器进行同步c;避免其他线程修改数据。在启用 read-only 后c;如果操作从服务器的用户没有 super 权限c;则对从服务器进行任何的修改会抛出错误（read-only 对拥有 super 权限的账号是不生效的）
双向主从架构与单向主从架构的区别是c;主库支持写操作c;备库去做主库同步；而双向架构c;是两台主库c;每台都支持写操作c;其中一台更新了数据c;另外一台去做同步操作c;始终保持两台服务器数据一致。
1、保证两台服务器 server_id 不同 2、检查两台是否都开启了 log_bin 参数 3、检查两台 binlog 是否设置基于行复制的格式 4、创建主从复制账号 5、在两台库上分别查询当前 binlog 和 pos 6、在两台库上分别配置主从（互为主从） 7、在两台库上开启主从同步c;查看备库状态信息等 8、插入数据验证双向主从架构是否实现互相数据同步
双向主从架构模式与单向主从的配置方式相似c;不做赘述。 注：双向主从架构模式不得设置 read-only 为 ON
级联主从在单向主从架构的基础上c;在第二个 slave 中设置第一个 slave 为 master 开启主从即可c;配置过程不再赘述。
多主一从c;也称多源复制c;就是把多台主库的数据同步到一个备库上c;备库会创建通往每个主库的管道。在 MySQL 5.7以前c;只能实现 一主一从、一主多从或多主多从的架构模式。
在 slave 上配置多个 master 时指定 chAnnel 名称c;同时在 start 时也根据 chAnnel 名称开启同步即可c;例如：
# 配置主从
mysql>CHANGE MASTER to MASTER_HOST='192.168.96.177',@H_367_183@mASTER_USER='Root',@H_367_183@mASTER_password='123456',@H_367_183@mASTER_LOG_FILE='binlog.000020',@H_367_183@mASTER_LOG_POS=1998 for chAnnel 'master1';
Query OK, 0 rows affected, 8 warnings (0.03 sec)
# 开启同步
mysql>start slave for chAnnel 'master1';
Query OK, 0 rows affected, 1 warnings (0.03 sec)
多主一从架构中c;对任意一个 master 做增删改操作时c;slave 都会同步此操作。而一般情况下为了保持主从数据一致 slave 只做读操作即可。
多源复制的优点：
半同步复制原理如图：
半同步复制提升了主从之间数据的一致性c;让复制更加安全可靠。
1、在主库中安装半同步复制插件并开启半同步复制功能
# 安装半同步复制插件
mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so';
Query OK, 0 rows affected, 1 warning (0.07 sec)
# 开启半同步复制
mysql> set global rpl_semi_sync_master_enabled=on;
Query OK, 0 rows affected (0.00 sec)
# 查询是否开启半同步复制功能
mysql> show variables like '%semi%';
+-------------------------------------------+------------+
| Variable_name | Value |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled | ON |
| rpl_semi_sync_master_timeout | 10000 |
| rpl_semi_sync_master_trace_level | 32 |
| rpl_semi_sync_master_wait_for_slave_count | 1 |
| rpl_semi_sync_master_wait_no_slave | ON |
| rpl_semi_sync_master_wait_point | AFTER_SYNC |
+-------------------------------------------+------------+
6 rows in set (0.03 sec)
2、在备库中安装半同步复制插件并开启半同步复制功能
@H_965_132@mysql> install plugin rpl_semi_sync_slave soname 'semisync_slave.so'; Query OK, 0 rows affected, 1 warning (0.01 sec) mysql> set global rpl_semi_sync_slave_enabled=on; Query OK, 0 rows affected (0.00 sec) mysql> show variables like '%semi%'; +-------------------------------------------+------------+ | Variable_name | Value | +-------------------------------------------+------------+ | rpl_semi_sync_master_enabled | OFF | | rpl_semi_sync_master_timeout | 10000 | | rpl_semi_sync_master_trace_level | 32 | | rpl_semi_sync_master_wait_for_slave_count | 1 | | rpl_semi_sync_master_wait_no_slave | ON | | rpl_semi_sync_master_wait_point | AFTER_SYNC | | rpl_semi_sync_slave_enabled | ON | | rpl_semi_sync_slave_trace_level | 32 | +-------------------------------------------+------------+ 8 rows in set (0.00 sec)
如果想要开机自启动半复制功能c;可以将 rpl_semi_sync_master_enabled 和 rpl_semi_sync_slave_enabled 参数写到 my.cnf 中。
3、在备库中重启 I/O 线程即可激活半同步复制。
@H_965_132@mysql> stop slave io_thread; Query OK, 0 rows affected, 2 warnings (0.01 sec) mysql> start slave io_thread; Query OK, 0 rows affected, 1 warning (0.02 sec)
4、在主库中查看半同步复制功能是否正常正常运行
@H_965_132@mysql> show global status like '%semi%'; +--------------------------------------------+-------+ | Variable_name | Value | +--------------------------------------------+-------+ | Rpl_semi_sync_master_clients | 1 | | Rpl_semi_sync_master_net_avg_wait_time | 0 | | Rpl_semi_sync_master_net_wait_time | 0 | | Rpl_semi_sync_master_net_waits | 0 | | Rpl_semi_sync_master_no_times | 0 | | Rpl_semi_sync_master_no_tx | 0 | | Rpl_semi_sync_master_status | ON | | Rpl_semi_sync_master_timefunc_@R_617_4895@ | 0 | | Rpl_semi_sync_master_tx_avg_wait_time | 0 | | Rpl_semi_sync_master_tx_wait_time | 0 | | Rpl_semi_sync_master_tx_waits | 0 | | Rpl_semi_sync_master_wait_pos_BACktraverse | 0 | | Rpl_semi_sync_master_wait_sessions | 0 | | Rpl_semi_sync_master_yes_tx | 0 | +--------------------------------------------+-------+ 14 rows in set (0.01 sec)
其中c;Rpl_semi_sync_master_clients 参数代表有一个备库连接到了主库c;并且是半同步复制方式。
5、经验证c;在主库中操作数据c;备库同步数据失败时c;会导致主库插入数据缓慢c;代表正在等待备库的响应结果c;等待超时了c;此时查看半同步复制状态c;被切换为了异步复制方式。而想从异步复制方式切换为半同步复制方式c;需要重启备库的 I/O thread 才行。
GTID（Global transaction ID）是一个已提交事务的编号c;并且是一个全局唯一的编号c;R_864_11845@ySQL5.6以后在主从复制类型上新增了 GTID 复制。是由 server_uuid 和事务 id 组成的c;即 GTID=server_uuid:transaction_idc;server_uuid 是在数据库启动过程中自动生成的c;每台机器的 server_uuid 都不同c;而 transaction_id 就是事务提交时由系统顺序分配的一个不会重复的序列号。
GTID 和异步复制、半同步复制类似c;只不过不再利用传统复制模式的 binlog 文件和 position 号了c;而是在备库 “change master to” 时使用 master_auto_position=1 的方式进行搭建c;这就让操作变的更加方便和可靠。
使用 GTID 模式搭建过程时c;主库my.cnf中要配置以下参数：
gitd_mode=on
enforce_gtid_consistency=on
log_bin=on
备库中要配置：
gitd_mode=on
enforce_gtid_consistency=on
log_slave_updates=1
配置好参数后c;如果是新搭建的主从环境c;就可以直接在库中之心 change master to 语句了c;如果是运行了一段期间的主库c;还需要利用备份方式从主库 dump 出数据到备库c;先完成基于某个点的 GTID 复制c;备库再从那个点之后再开始同步。前面实战的配置方式就是使用的 GTID 模式。
以上是大佬教程为你收集整理的从理论到实战，彻底搞懂MySQL主从复制原理全部内容，希望文章能够帮你解决从理论到实战，彻底搞懂MySQL主从复制原理所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。