MySQL数据库的主从复制原理及其意义
 
首先，我们要明确的一点是什么是数据库的主从复制？简单的来说，数据库由于自身的特点（脆弱性，不易维护），例如，突发事件停电，人为因素误删库，数据流量过大造成硬盘空间过满，sql语句设计不合理，等等因素，造成数据的丢失或者损坏以及无法及时存入数据，那么主从复制可能解决这些问题。
 
主从复制，指的是建立一个和主数据库环境一模一样的从数据库环境，也就是说，主从是单独的，独立的两套MySQL数据库，版本一致，其中运行MySQL的系统也最好尽量的一致，MySQL内的库也完全一致，通过binlog日志系统，同步数据库的数据，并在预先备份过binlog日志的时候，如果出现了问题，通过binlog日志来恢复数据库。
 
能够实现主从复制，完全是由于binlog日志的作用，那么什么是binlog？
 
 
 
、binlog（像不像广东人经常说的冰狗？？），字面意思为程序的日志，既然是MySQL的日志，自然指的是MySQL运行时所产生的日志喽。
 
　　1、MySQL的二进制日志binlog可以说是MySQL最重要的日志，它记录了所有的DDL和DML语句（除了数据查询语句select）,以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。
 
　　　　a、DDL
 
　　　　　　----Data Definition Language 数据库定义语言 
 
　　　　　　主要的命令有create、alter、drop等，ddl主要是用在定义或改变表(table)的结构,数据类型，表之间的连接和约束等初始工作上，他们大多在建表时候使用。
 
　　　　b、DML
 
　　　　　　----Data Manipulation Language 数据操纵语言
 
　　　　　　主要命令是slect,update,insert,delete,就像它的名字一样，这4条命令是用来对数据库里的数据进行操作的语言
 
              c. DCL
 
               ----Data Control Language 数据库控制语言如grant,deny,revoke等，只有管理员才有这样的权限。你要普通用户提权过了，那么，当我没说。和主从复制没多大关系，也就不讲解了。
 
结论：binlog日志记录了数据库的所有操作，除了权限类的和查询类的操作。那么，binlog在哪里？首先，默认也就是全新安装后的MySQL是没有开启binlog的，如果开启了binlog，那么保存日志的文件在MySQL的数据库目录下，也就是和其内建库，比如mysql，information_schema这样的数据库的上面一层目录，文件名开始为master，结尾以00000+数字结尾，以及以index结尾的文件。我这么说的是Linux的目录下。通常，MySQL也是装在Linux下。
 
 
master打头的两个文件即为binlog的文件，00000*结尾的文件是二进制文件，无法通过文本编辑器 比如vim打开，或者cat命令查看，以index结尾的文件可以使用文本编辑器打开，也可以使用cat命令查看。index结尾的文件记录了所有可用的二进制文件的索引，00000*记录的是数据库的所有ddl和dml语句事件，除了select查询事件。
 
由于我在MySQL的配置文件，my.cnf文件内做了相应配置，并重启了mysql服务，才会出现这两个文件哦。
 
 
 如何开启binlog日志？  
 
首先，我们需要查看binlog日志的状态，是否开启？
 
 
这样的就是开启的，log_bin 的值为on表示开启，如果为off，需要打开my.cnf文件，将该日志功能打开，由于是服务日志更改，因此必须重启服务。         
 
 
 
红色箭头表示要添加的两行。椭圆表示打开的哪个文件以及添加的位置。
 
彻底的总结：
 
MySQL数据库的主从复制是通过开启binlog日志功能，通过日志内记录的sql语句，将主数据库的sql语句传送到从数据库并执行，从而达到主从复制同步数据的目的。也就是说，第一关键是binlog日志的生成，第二关键那么就是从数据库获取到日志内的sql语句，并执行。
 
主从复制的意义在于，不将鸡蛋装在一个篮子内，并且，由于binlog的特性（保存了sql事件），我们可以实现一定程度的备份。

 
 
https://www.cnblogs.com/syncnavigator/p/10189644.html
 https://blog.csdn.net/cwb521sxm/article/details/97303289
 https://blog.csdn.net/zhanghan18333611647/article/details/91638443
 
 
一、MySQL的数据库主从复制原理
 MySQL的主从复制都是单线程的操作，主库对所有DDL和DML产生的日志写进binlog，由于binlog是顺序写，所以效率很高。Slave的IO Thread线程从主库中binlog中读取取日志。Slave的SQLThread线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随即的，不是顺序的，成本高很多。由于SQL Thread也是单线程的，如果slave上的其他查询产生lock争用，又或者一个DML语句（大事务、大查询）执行了几分钟，那么所有之后的DML会等待这个DML执行完才会继续执行，这就导致了延时。
 
主从同步延迟的引发原因
 
1、Master负载

2、Slave负载

3、网络延迟

4、机器配置（cpu、内存、硬盘）
 
总之，当主库的并发较高时，产生的DML数量超过slave的SQL Thread所能处理的速度，或者当slave中有大型query语句产生了锁等待那么延时就产生了。
 
同步延迟的解决方案
 
最简单的减少slave同步延时，尽量让主库的DDL快速执行。还有就是主库是写，对数据安全性较高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也可以设置为0来提高sql的执行效率，从库关闭binlog记录。另外就是使用比主库更好的硬件设备作为slave。
 在业务架构上将不同的业务分布到不同的物理数据库上，同一个业务分库架构，在业务层与数据库之间增加分布式缓存以便减少主库的压力。
 在mysql 5.7版本后开始支持多线程并行复制技术enhanced multi-threaded slave（简称MTS）。
 MySQL并行同步机制
 
并行同步在MySQL5.6就开始支持，只不过在5.6时是基于schema的，也就是基于库的，相比于5.7的机制要逊色的多。MySQL 5.7才可称为真正的并行复制，这其中最为主要的原因就是slave服务器的回放与主机是一致的。即master服务器上是怎么并行执行的slave上就怎样进行并行回放。不再有库的并行复制限制。
 
从MySQL官方来看，其并行复制的原本计划是支持表级的并行复制和行级的并行复制，行级的并行复制通过解析ROW格式的二进制日志的方式来完成。但是最终出现给小伙伴的确是在开发计划中称为：MTS: Prepared transactions slave parallel applier。该并行复制的思想最早是由MariaDB的Kristain提出，并已在MariaDB 10中出现，相信很多选择MariaDB的小伙伴最为看重的功能之一就是并行复制。
 
MySQL 5.7并行复制的思想简单易懂，一言以蔽之：一个组提交的事务都是可以并行回放，因为这些事务都已进入到事务的prepare阶段，则说明事务之间没有任何冲突（否则就不可能提交）。为了兼容MySQL 5.6基于库的并行复制，5.7引入了新的变量slave-parallel-type，其可以配置的值有：
 
• DATABASE：默认值，基于库的并行复制方式
 
• LOGICAL_CLOCK：基于组提交的并行复制方式
 
MySQL在binlog中定义了两个Logical_clock的变量：
 
• max_c ommitted_transaction：记录上次组提交时的logical_clock，代表上述mysqlbinlog中的last_committed
 
• transaction_counter：记录当前组提交中各事务的logcial_clock，代表上述mysqlbinlog中的sequence_number
 
通过工具检查binlog文件，可以发现较之原来的二进制日志内容多了last_committed和sequence_number，last_committed表示事务提交的时候，上次事务提交的编号，如果事务具有相同的last_committed，表示这些事务都在一组内，可以进行并行的回放。例如上述last_committed为0的事务有6个，表示组提交时提交了6个事务，而这6个事务在从机是可以进行并行回放的。
 
提升同步的策略中，有很多实现，包括MySQL各版本的实现及MariaDB等分支的实现上，按按粒度区分的三个策略，粒度从粗到细是按库、按表、按行，而MySQL5.7按照commit_id的策略适用范围更广，改进策略并发性更优。
 
MySQL主从复制实际上基于二进制日志，原理可以用一张图来表示：
 
MySQL数据库主从同步延迟分析及解决方案
 
分为四步走：
 
 
主库对所有DDL和DML产生的日志写进binlog；
 
 
主库生成一个 log dump 线程，用来给从库I/O线程读取binlog；
 
 
从库的I/O Thread去请求主库的binlog，并将得到的binlog日志写到relay log文件中；
 
 
从库的SQL Thread会读取relay log文件中的日志解析成具体操作，将主库的DDL和DML操作事件重放。
 
 
关于DDL和DML
 
SQL语言共分为四大类：查询语言DQL，控制语言DCL，操纵语言DML，定义语言DDL。
 
DQL：可以简单理解为SELECT语句；
 
DCL：GRANT、ROLLBACK和COMMIT一类语句；
 
DML：数据库操作语言：SQL中处理数据库中的数据
 
其主要命令有INSERT,UPDATE,DELETE等，
 
DDL：数据库定义语言：定义数据库的结构。
 
其主要命令有CREATE，ALTER，DROP
 
二、主从复制存在的问题
 
 
主库宕机后，数据可能丢失；
 
 
主从同步延迟。
 
 
三、MySQL数据库主从同步延迟产生原因
 原因分析
 
MySQL的主从复制都是单线程的操作，主库对所有DDL和DML产生的日志写进binlog，由于binlog是顺序写，所以效率很高。Slave的SQL Thread线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随即的，不是顺序的，成本高很多。另一方面，由于SQL Thread也是单线程的，当主库的并发较高时，产生的DML数量超过slave的SQL Thread所能处理的速度，或者当slave中有大型query语句产生了锁等待那么延时就产生了。
 
常见原因：Master负载过高、Slave负载过高、网络延迟、机器性能太低、MySQL配置不合理。
 
四、主从延时排查方法
 通过监控 show slave status 命令输出的Seconds_Behind_Master参数的值来判断：
 
NULL，表示io_thread或是sql_thread有任何一个发生故障；
 
0，该值为零，表示主从复制良好；
 
正值，表示主从已经出现延时，数字越大表示从库延迟越严重。
 
五、解决方案
 解决数据丢失的问题：
 
半同步复制
 
从MySQL5.5开始，MySQL已经支持半同步复制了，半同步复制介于异步复制和同步复制之间，主库在执行完事务后不立刻返回结果给客户端，需要等待至少一个从库接收到并写到relay log中才返回结果给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一个TCP/IP往返耗时的延迟。
 
主库配置sync_binlog=1，innodb_flush_log_at_trx_commit=1
 
sync_binlog的默认值是0，MySQL不会将binlog同步到磁盘，其值表示每写多少binlog同步一次磁盘。
 
innodb_flush_log_at_trx_commit为1表示每一次事务提交或事务外的指令都需要把日志flush到磁盘。
 
注意:将以上两个值同时设置为1时，写入性能会受到一定限制，只有对数据安全性要求很高的场景才建议使用，比如涉及到钱的订单支付业务，而且系统I/O能力必须可以支撑！
 
解决从库复制延迟的问题：
 
 
优化网络
 
 
升级Slave硬件配置
 
 
Slave调整参数，关闭binlog，修改innodb_flush_log_at_trx_commit参数值
 
 
升级MySQL版本到5.7，使用并行复制
 
 
1 如何写频繁，水平拆分，减少单片写数量
 7 避免复杂DML操作
 

概念
 
MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主数据库中的所有数据库或者特定的数据库，或者特定的表
 
主要用途
 
1. 读写分离
 
在开发工作中，有时候会遇见某个sql 语句需要锁表，导致暂时不能使用读的服务，这样就会影响现有业务，使用主从复制，让主库负责写，从库负责读，这样，即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运作。
 
2. 数据实时备份
 
当系统中某个节点发生故障时，可以方便的故障切换
 
3. 高可用HA和架构扩展
 
随着系统中业务访问量的增大，如果是单机部署数据库，就会导致I/O访问频率过高。有了主从复制，增加多个数据存储节点，将负载分布在多个从节点上，降低单机磁盘I/O访问的频率，提高单个机器的I/O性能。
 
主从形式
 
1. 一主一从
 

 一主多从，提高系统的读性能。一主一从和一主多从是最常见的主从架构，实施起来简单并且有效，不仅可以实现HA，而且还能读写分离，进而提升集群的并发能力。
 
2. 多主一从 （从5.7开始支持）
 

 多主一从可以将多个mysql数据库备份到一台存储性能比较好的服务器上。
 
3. 双主复制
 
双主复制，也就是互做主从复制，每个master既是master，又是另外一台服务器的slave。这样任何一方所做的变更，都会通过复制应用到另外一方的数据库中。
 
4. 级联复制
 
 
级联复制模式下，部分slave的数据同步不连接主节点，而是连接从节点。因为如果主节点有太多的从节点，就会损耗一部分性能用于replication，那么我们可以让3~5个从节点连接主节点，其它从节点作为二级或者三级与从节点连接，这样不仅可以缓解主节点的压力，并且对数据一致性没有负面影响。
 
主从复制原理
 
MySQL主从复制涉及到三个线程，一个运行在主节点（log dump thread），其余两个(I/O thread, SQL thread)运行在从节点，如下图所示:
 
 
1. 主节点 binary log dump 线程
 
当从节点连接主节点时，主节点会创建一个log dump 线程，用于发送bin-log的内容。在读取bin-log中的操作时，此线程会对主节点上的bin-log加锁，当读取完成，甚至在发动给从节点之前，锁会被释放。
 
2.从节点I/O线程
 
当从节点上执行start slave命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库中更新的bin-log。I/O线程接收到主节点binlog dump 进程发来的更新之后，保存在本地relay-log中。
 
3.从节点SQL线程
 
SQL线程负责读取relay log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。
 
对于每一个主从连接，都需要三个进程来完成。当主节点有多个从节点时，主节点会为每一个当前连接的从节点建一个binary log dump 进程，而每个从节点都有自己的I/O进程，SQL进程。从节点用两个线程将从主库拉取更新和执行分成独立的任务，这样在执行同步数据任务的时候，不会降低读操作的性能。比如，如果从节点没有运行，此时I/O进程可以很快从主节点获取更新，尽管SQL进程还没有执行。如果在SQL进程执行之前从节点服务停止，至少I/O进程已经从主节点拉取到了最新的变更并且保存在本地relay日志中，当服务再次起来之后，就可以完成数据的同步。
 
要实施复制，首先必须打开Master 端的binary log（bin-log）功能，否则无法实现。
 
因为整个复制过程实际上就是Slave 从Master 端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。如下图所示：
 
 
复制的基本过程如下：
 
从节点上的I/O 进程连接主节点，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；
主节点接收到来自从节点的I/O请求后，通过负责复制的I/O进程根据请求信息读取指定日志指定位置之后的日志信息，返回给从节点。返回信息中除了日志所包含的信息之外，还包括本次返回的信息的bin-log file 的以及bin-log position；从节点的I/O进程接收到内容后，将接收到的日志内容更新到本机的relay log中，并将读取到的binary log文件名和位置保存到master-info 文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log 的哪个位置开始往后的日志内容，请发给我”
Slave 的 SQL线程检测到relay-log 中新增加了内容后，会将relay-log的内容解析成在祝节点上实际执行过的操作，并在本数据库中执行。
 
主从复制模式
 
MySQL 主从复制默认是异步的模式。MySQL增删改操作会全部记录在binary log中，当slave节点连接master时，会主动从master处获取最新的bin log文件。并把bin log中的sql relay。
 
1. 异步模式
 
异步模式如下图所示，这种模式下，主节点不会主动push bin log到从节点，这样有可能导致failover的情况下，也许从节点没有即时地将最新的bin log同步到本地
 
 
全同步模式
 
全同步模式是指主节点和从节点全部执行了commit并确认才会向客户端返回成功
 
总结
 
Mysql 主从复制是mysql 高可用，高性能的基础，有了这个基础，mysql 的部署会变得简单、灵活并且具有多样性，从而可以根据不同的业务场景做出灵活的调整。

什么是主从复制
 
MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，数据的更新可以在远程连接上进行，从节点可以复制主数据库中的所有数据库或者特定的数据库，或者特定的表。
 主从复制是MySQL最重要的功能之一。对于多级复制，数据库服务器即可充当主机，也可充当从机。MySQL主从复制的基础是主服务器对数据库修改记录二进制日志，从服务器通过主服务器的二进制日志自动执行更新。
 
为什么要主从复制
 
随着系统中业务访问量的增大，如果是单机部署数据库，就会导致I/O访问频率过高。有了主从复制，增加多个数据存储节点，将负载分布在多个从节点上，降低单机磁盘I/O访问的频率，提高单个机器的I/O性能；
一般会让主库负责写，从库负责读，这样，即使主库出现了锁表的情景，通过读从库也可以保证业务的正常运作；
从库可以实时从主库进行复制，这样就可以做数据的热备；
 
主从复制原理是什么
 
 
 
binlog
 主库中可以设置binlog，binlog是主库中保存更新事件日志的二进制文件。
 
 
主节点 binary log dump 线程
 如上图所示：当从节点连接主节点时，主节点会创建一个log dump 线程，用于发送bin-log的内容。在读取bin-log中的操作时，此线程会对主节点上的bin-log加锁，当读取完成，甚至在发动给从节点之前，锁会被释放。
 
 
从节点I/O线程
 当从节点上执行start slave命令之后，从节点会创建一个I/O线程用来连接主节点，请求主库中更新的bin-log。I/O线程接收到主节点binlog dump 进程发来的更新之后，保存在本地relay-log中。
 
 
从节点SQL线程
 SQL线程负责读取relay log中的内容，解析成具体的操作并执行，最终保证主从数据的一致性。
 对于每一个主从连接，都需要三个进程来完成。当主节点有多个从节点时，主节点会为每一个当前连接的从节点建一个binary log dump 进程，而每个从节点都有自己的I/O进程，SQL进程。从节点用两个线程将从主库拉取更新和执行分成独立的任务，这样在执行同步数据任务的时候，不会降低读操作的性能。比如，如果从节点没有运行，此时I/O进程可以很快从主节点获取更新，尽管SQL进程还没有执行。如果在SQL进程执行之前从节点服务停止，至少I/O进程已经从主节点拉取到了最新的变更并且保存在本地relay日志中，当服务再次起来之后，就可以完成数据的同步。
 
 
主从复制过程说明
 首先必须打开Master 端的binary log（bin-log）功能，否则无法实现。
 因为整个复制过程实际上就是Slave 从Master 端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。如下图所示：
 
 
 
节点上的I/O 进程连接主节点，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；
主节点接收到来自从节点的I/O请求后，通过负责复制的I/O进程根据请求信息读取指定日志指定位置之后的日志信息，返回给从节点。返回信息中除了日志所包含的信息之外，还包括本次返回的信息的bin-log file 的以及bin-log position；
从节点的I/O进程接收到内容后，将接收到的日志内容更新到本机的relay log中，并将读取到的binary log文件名和位置保存到master-info 文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log 的哪个位置开始往后的日志内容，请发给我”；
Slave 的 SQL线程检测到relay-log 中新增加了内容后，会将relay-log的内容解析成在祝节点上实际执行过的操作，并在本数据库中执行。
 
主从配置步骤（基于linux）
 
一、 主库配置
 
1、修改主库配置文件my.cnf
 
[mysqld]
basedir=/usr/local/mysql
datadir=/data/mysql
socket=/tmp/mysql.sock
user=mysql
port=3306
character-set-server=utf8mb4
# cancle password
skip-grant-tables
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

# 配置主从，注意一定要在[mysqld]节点下
server-id=1
log-bin=/data/mysql/mysqlbin
binlog-ignore-db=mysql
binlog-do-db=aemm
binlog-do-db=aoss
read_only = 0
expire_logs_days = 15

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
 
主要参数说明：
 
server-id=1：配置server-id,不能和从库重复
log-bin=/data/mysql/mysqlbin：配置log-bin文件名
binlog-ignore-db=mysql：配置不复制的库
binlog-do-db=testdb1：配置要复制的库
binlog-do-db=testdb2：可配置多个要复制的库
read_only：0表示可读可写，1表示只读（也可写成on）
 
其他配置参数说明：
 
 
expire_logs_days：通过此来实现master自动删除binlog
 
 
innodb_flush_log_at_trx_commit=1：
 此参数表示在事务提交时，处理重做日志的方式；此变量有三个可选值0，1，2：
 0：当事务提交时，并不将事务的重做日志写入日志文件，而是等待每秒刷新一次
 1：当事务提交时，将重做日志缓存的内容同步写到磁盘日志文件，为了保证数据一致性，在replication环境中使用此值。
 2：当事务提交时，将重做日志缓存的内容异步写到磁盘日志文件（写到文件系统缓存中）
 建议必须设置innodb_flush_log_at_trx_commit=1
 
 
sync_binlog=1
 <1>此参数表示每写缓冲多少次就同步到磁盘；
 <2>sync_binlog=1表示同步写缓冲和磁盘二进制日志文件，不使用文件系统缓存；
 <3>在使用innodb事务引擎时，在复制环境中，为了保证最大的可用性，都设置为“1”，但会对影响io的性能。
 <4>即使设置为“1”，也会有问题发生：假如当二进制日志写入磁盘，但事务还没有commit，这个时候宕机，当服务再次起来恢复的时候，无法回滚以及记录到二进制日志的未提交的内容；
 这个时候就会造成master和slave数据不一致
 <5>解决方案：
 需要参数innodb_support_xa=1来保证。建议必须设置。
 innodb_support_xa=1
 此参数与XA事务有关，它保证了二进制日志和innodb数据文件的同步，保证复制环境中数据一致性。建议必须设置。
 
 
binlog-do-table=skate_tab
 只记录指定表的更新到二进制日志中
 
 
log_slave_updates=1
 此参数控制slave数据库是否把从master接受到的log并在本slave执行的内容记录到slave的二进制日志中
 在级联复制环境中（包括双master环境），这个参数是必须的
 
 
binlog_format=statement|row|mixed
 控制以什么格式记录二进制日志的内容，默认是mixed
 
 
max_binlog_size
 master的每个二进制日志文件的大小，默认1G
 
 
binlog_cache_size
 1、所有未提交的事务都会被记录到一个缓存或临时文件中，待提交时，统一同步到二进制日志中，
 2、此变量是基于session的，每个会话开启一个binlog_cache_size大小的缓存。
 3、通过变量“Binlog_cache_disk_use”和“Binlog_cache_use”来设置binlog_cache_size的大小。
 说明：
 Binlog_cache_disk_use： 使用临时文件写二进制日志的次数
 Binlog_cache_use： 使用缓冲记写二进制的次数
 
 
auto_increment_increment=2 //增长的步长
 auto_increment_offset=1 //起始位置
 在双master环境下可以防止键值冲突
 
 
2、重启数据库，并授权给从库
 
 
授权给从库
 grant replication slave on *.* to 'root'@'11.10.11.10' identified by '123456';
 
 
刷新配置
 flush privileges;
 
 
查看主库状态
 show master status;
 
 主要参数说明：
 1.File：logbin文件；
 2.Position：指主库当前复制的起始位置；
 3.Binlog_Do_DB：要复制的数据库；
 4.Binlog_Ignore_DB：不被复制的数据库。
 
 
查看mysqlbin.000003文件，存储在数据库存储目录中，在my.cnf中可以查看
 datadir=/data/mysql
 
 
二、 从库配置
 
1、修改从库配置文件my.cnf
 
[mysqld]
basedir=/usr/local/mysql
datadir=/data/mysql
socket=/tmp/mysql.sock
user=mysql
port=3306
character-set-server=utf8mb4
# cancle password
#skip-grant-tables
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# skip-grant-tables

# 从库配置
server-id=2
log-bin=/data/mysql/mysqlbin
binlog-ignore-db=mysql
binlog-do-db=aemm
binlog-do-db=aoss
skip_slave_start

#relay-log=slave-relay-bin
#relay-log-index=slave-relay-bin.index
#read_only = 1
#log_slave_updates=1
#sync_master_info=1
#sync_relay_log=1
#sync_relay_log_info=1

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
 
主要参数说明：
 
server-id=2：配置server-id,不能和主库或其他从库重复
log-bin=/data/mysql/mysqlbin：配置log-bin文件名
binlog-ignore-db=mysql：配置不复制的库
binlog-do-db=testdb1：配置要复制的库
binlog-do-db=testdb2：可配置多个要复制的库
skip_slave_start：复制进程就不会随着数据库的启动而启动，避免主从数据不一致
 
其他配置参数说明：
 
 
log-bin=mysql-bin
 和master的含义一样，开启二进制
 
 
relay-log=relay-bin
 中继日志文件的路径名称
 
 
relay-log-index=relay-bin
 中继日志索引文件的路径名称
 
 
log_slave_updates=1
 和master的含义一样，如上
 
 
read_only=1
 1、使数据库只读，此参数在slave的复制环境和具有super权限的用户不起作用，
 2、对于复制环境设置read_only=1非常有用，它可以保证slave只接受master的更新，而不接受client的更新。
 3、客户端设置：
 mysq> show global variables like “%read_only%”;
 mysq> set global read_only=1
 
 
skip_slave_start
 使slave在mysql启动时不启动复制进程，mysql起来之后使用 start slave启动，建议必须
 
 
replicate-do-db
 只复制指定db
 
 
replicate-do-table
 只复制指定表
 
 
replicate-ingore-table
 忽略指定表
 
 
replicate_wild_do_table=skatedb.%
 模糊匹配复制指定db
 
 
auto_increment_increment=2
 auto_increment_offset=1
 和master含义一样，参考如上
 
 
log_slow_slave_statements
 在slave上开启慢查询日志，在query的时间大于long_query_time时，记录在慢查询日志里
 
 
max_relay_log_size
 slave上的relay log的大小，默认是1G
 
 
relay_log_info_file
 中继日志状态信息文件的路径名称
 
 
relay_log_purge
 当relay log不被需要时就删除，默认是on
 SET GLOBAL relay_log_purge=1
 
 
`replicate-rewrite-db=from_name->to_name
 数据库的重定向，可以把分库汇总到主库便于统计分析
 
 
2、配置主数据库
 
 
配置主数据库地址和logbin
 change master to master_host='11.18.22.32', master_user='root', master_password='123456', master_log_file='mysqlbin.000003', master_log_pos=707;
 
 
启动从数据库服务
 start slave;
 停止命令是：
 stop slave;
 
 
查看从数据库状态，启动IO和SQL线程
 show slave status \G;
 
 注：图中显示的配置参数都是配过的，红框中IO线程和SQL线程状态都是Yes，表示从库配置启动成功。
 
 
MySQL 主从复制模式
 
MySQL 主从复制默认是异步的模式。MySQL增删改操作会全部记录在binary log中，当slave节点连接master时，会主动从master处获取最新的bin log文件。并把bin log中的sql relay。
 
一、异步模式（mysql async-mode）
 
异步模式如下图所示，这种模式下，主节点不会主动push bin log到从节点，这样有可能导致failover的情况下，也许从节点没有即时地将最新的bin log同步到本地。
 
 二、半同步模式(mysql semi-sync)
 
这种模式下主节点只需要接收到其中一台从节点的返回信息，就会commit；否则需要等待直到超时时间然后切换成异步模式再提交；这样做的目的可以使主从数据库的数据延迟缩小，可以提高数据安全性，确保了事务提交后，binlog至少传输到了一个从节点上，不能保证从节点将此事务更新到db中。性能上会有一定的降低，响应时间会变长。如下图所示：
 
 半同步模式不是mysql内置的，从mysql 5.5开始集成，需要master 和slave 安装插件开启半同步模式。
 
三、全同步模式
 
全同步模式是指主节点和从节点全部执行了commit并确认才会向客户端返回成功。
 
binlog记录格式
 MySQL 主从复制有三种方式：基于SQL语句的复制（statement-based replication，SBR），基于行的复制（row-based replication，RBR)，混合模式复制（mixed-based replication,MBR)。对应的binlog文件的格式也有三种：STATEMENT,ROW,MIXED。
 
 
Statement-base Replication(SBR)就是记录sql语句在bin log中，Mysql 5.1.4 及之前的版本都是使用的这种复制格式。优点是只需要记录会修改数据的sql语句到binlog中，减少了binlog日质量，节约I/O，提高性能。缺点是在某些情况下，会导致主从节点中数据不一致（比如sleep(),now()等）。
 
 
Row-based Relication(RBR)是mysql master将SQL语句分解为基于Row更改的语句并记录在bin log中，也就是只记录哪条数据被修改了，修改成什么样。优点是不会出现某些特定情况下的存储过程、或者函数、或者trigger的调用或者触发无法被正确复制的问题。缺点是会产生大量的日志，尤其是修改table的时候会让日志暴增,同时增加bin log同步时间。也不能通过bin log解析获取执行过的sql语句，只能看到发生的data变更。
 
 
Mixed-format Replication(MBR)，MySQL NDB cluster 7.3 和7.4 使用的MBR。是以上两种模式的混合，对于一般的复制使用STATEMENT模式保存到binlog，对于STATEMENT模式无法复制的操作则使用ROW模式来保存，MySQL会根据执行的SQL语句选择日志保存方式。
 
 
四、GTID复制模式
 
 
在传统的复制里面，当发生故障，需要主从切换，需要找到binlog和pos点，然后将主节点指向新的主节点，相对来说比较麻烦，也容易出错。在MySQL 5.6里面，不用再找binlog和pos点，我们只需要知道主节点的ip，端口，以及账号密码就行，因为复制是自动的，MySQL会通过内部机制GTID自动找点同步。
 
 
多线程复制（基于库），在MySQL 5.6以前的版本，slave的复制是单线程的。一个事件一个事件的读取应用。而master是并发写入的，所以延时是避免不了的。唯一有效的方法是把多个库放在多台slave，这样又有点浪费服务器。在MySQL 5.6里面，我们可以把多个表放在多个库，这样就可以使用多线程复制。
 
 
基于GTID复制实现的工作原理
 
主节点更新数据时，会在事务前产生GTID，一起记录到binlog日志中；
从节点的I/O线程将变更的bin log，写入到本地的relay log中；
SQL线程从relay log中获取GTID，然后对比本地binlog是否有记录（所以MySQL从节点必须要开启binary log）；
如果有记录，说明该GTID的事务已经执行，从节点会忽略；
如果没有记录，从节点就会从relay log中执行该GTID的事务，并记录到bin log；
在解析过程中会判断是否有主键，如果没有就用二级索引，如果有就用全部扫描。
 
参考链接
 
本文只为整理学习笔记，所以摘录和参考了很多博客，原文链接如下所示：
 
https://www.cnblogs.com/qianniao12/p/8011222.html
https://www.cnblogs.com/kevingrace/p/10095332.html
https://www.jb51.net/article/136828.htm
https://baijiahao.baidu.com/s?id=1617888740370098866&wfr=spider&for=pc
https://www.cnblogs.com/hoohack/p/7149234.html