该文不谈及良好的主从复制拓扑结构和主从复制中可能出现的问题，以后有时间再写。
概述
复制解决的基本问题是让一台服务器的数据与其他服务器保持同步。一台主库的数据可以同步到多台备库上，备库本身也可以被配置成另外一台服务器的主库。
MySQL 支持两种复制方式：基于行的复制和基于语句的复制。这两种方式都是通过在主库上记录 binlog，在备库重放日志的方式来实现异步的数据复制。这意味着，在同一时间点备库上的数据可能与主库存在不一致，并且保证主备之间的延迟。
复制通常不会增加主库的开销，主要是启用 binlog 带来的开销，但出于备份或及时从崩溃中恢复的目的，这点开销也是必要的。除此之外，每个备库也会对主库增加一些负载（网络IO），尤其当备库请求从主库读取旧的 binlog 时，可能会造成更高的 IO 开销。
通过复制可以将读操作指向备库来获得更好的读扩展，但对于写操作，除非设计得当，否则并不适合通过复制来扩展写操作。
复制解决的问题
- 数据分布
- 负载均衡，读写分离
- 备份
- 高可用和故障切换
复制原理
复制如何工作
- 在主库上把数据更改记录在
binlog中（这些记录称为二进制日志事件） - 备库将主库上的日志复制到自己的中继日志中
- 备库读取中继日志中的事件，将其重放到备库数据之上
基于语句的复制
主库会记录那些造成数据更改的查询，当备库读取并重放这些事件时，实际上只是把主库上执行过的 SQL 再执行一遍。 即binlog的statement模式
优点：
1. 实现简单
2. binlog 中的事件更加紧凑
问题：
1. 同一条 SQL 在主库和备库上执行的时间可能稍微或很不相同，因此在传输的 binlog 中，
除了 SQL，还有一些元数据，比如时间戳
2. 一些无法被正确复制的 SQL，存储过程、触发器
3. 更新必须是串行的，这需要更多的锁
基于行的复制
会将实际数据记录在 binlog 中。即binlog的row模式
好处：
- 可以正确地复制每一行，一些语句可以被更加有效地复制
- 复制更加高效（但也视情况而定）
搭建步骤
master
- 在master的配置文件中，配置如下内容：
#mysql 服务ID,保证整个集群环境中唯一
server-id=1
#mysql binlog 日志的存储路径和文件名，主从复制是基于binlog的
log-bin=/var/lib/mysql/mysqlbin
#错误日志,默认已经开启
#log-err
#mysql的安装目录
#basedir
#mysql的临时目录
#tmpdir
#mysql的数据存放目录
#datadir
#是否只读,1 代表只读, 0 代表读写
read-only=0
#忽略的数据, 指不需要同步的数据库
binlog-ignore-db=mysql
#指定同步的数据库
#binlog-do-db=db01
- 在客户端中建同步数据的账户，并且进行授权操作：
grant replication slave on *.* to 'slave1'@'slave_host' identified by 'password';
flush privileges;
如果需要配置多个从机就创建多个账户，'slave_host'代表从机的ip地址。
- 查看master状态：
show master status;
- File : 从哪个日志文件开始推送日志文件
- Position ： 从哪个位置开始推送日志
- Binlog_Ignore_DB : 指定不需要同步的数据库
slave
- 在 slave 端配置文件中，配置如下内容：
#mysql服务端ID,唯一
server-id=2
#指定binlog日志
log-bin=/var/lib/mysql/mysqlbin
- 在客户端内执行如下指令 ：
change master to master_host= 'master_host', master_user='slave1', master_password='password', master_log_file='mysqlbin.000001', master_log_pos=413;
指定当前从库对应的主库的IP地址，用户名，密码，从哪个日志文件开始的那个位置开始同步推送日志。（这些都是在master status中看到的）
- 开启同步操作
start slave;
show slave status;
- 停止同步操作
stop slave;
原创文章，作者：彭晨涛，如若转载，请注明出处：https://www.codetool.top/article/mysql%e4%b8%bb%e4%bb%8e%e5%a4%8d%e5%88%b6%e7%ae%80%e4%bb%8b/
