在实际的生产中，为了解决Mysql的单点故障，一般都会采用「主备模式」。
林甸ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景，ssl证书未来市场广阔！成为成都创新互联公司的ssl证书销售渠道，可以享受市场价格4-6折优惠！如果有意向欢迎电话联系或者加微信：13518219792（备注：SSL证书合作）期待与您的合作！
MySQL几乎所有的高可用架构，都直接依赖于 binlog。虽然这些高可用架构已经呈现出越来越复杂的趋势，但都是从最基本的一主一备演化过来的。
下图为主备切换流程
在状态 1 中，客户端的读写都直接访问节点 A，而节点 B 是 A 的备库，只是将 A 的更新都同步过来，到本地执行。这样可以保持节点 B 和 A 的数据是相同的。
当需要切换的时候，就切成状态 2。这时候客户端读写访问的都是节点 B，而节点 A 是 B 的备库。
在状态 1 中，虽然节点 B 没有被直接访问，但是依然建议把节点 B（也就是备库）设置成只读（readonly）模式。这样做，有以下几个考虑：
图下图 中画出的就是一个 update 语句在节点 A 执行，然后同步到节点 B 的完整流程图。
备库 B 跟主库 A 之间维持了一个长连接。主库 A 内部有一个线程，专门用于服务备库 B 的这个长连接。一个事务日志同步的完整过程是这样的：
在备库 B 上通过 change master 命令，设置主库 A 的 IP、端口、用户名、密码，以及要从哪个位置开始请求 binlog，这个位置包含文件名和日志偏移量。
在备库 B 上执行 start slave 命令，这时候备库会启动两个线程，就是图中的 io_thread 和 sql_thread。其中 io_thread 负责与主库建立连接。
主库 A 校验完用户名、密码后，开始按照备库 B 传过来的位置，从本地读取 binlog，发给 B。
备库 B 拿到 binlog 后，写到本地文件，称为中转日志（relay log）。
sql_thread 读取中转日志，解析出日志里的命令，并执行。
主库需要复制新增binlog到从库才能完成同步，这个同步过程就是同步延迟。主从延迟最直接的表现是，备库消费中转日志（relay log）的速度，比主库生产 binlog 的速度要慢。
「同步策略」：Master会等待所有的Slave都回应后才会提交，这个主从的同步的性能会严重的影响。
「半同步策略」：Master至少会等待一个Slave回应后提交。
「异步策略」：Master不用等待Slave回应就可以提交。
「延迟策略」：Slave要落后于Master指定的时间。
对于不同的业务需求，有不同的策略方案，但是一般都会采用最终一致性，不会要求强一致性，毕竟强一致性会严重影响性能。
大致步骤如下：主MySQL服务器：192.168.3.1备MySQL服务器：192.168.3.2配置文件路径：/etc/my点吸烟 fMySQL服务状态：停止-------------------------主服务器配置-------------------编辑配置文件：vi
/etc/my点吸烟 f找到[mysqld]在它下面添加内容：server-id=1log-bin=backuplogbinlog-do-db=test#如果有多个数据库需要同步，添加多行即可#binlog-do-db=test2保存my点吸烟 f配置文件。启动mysql：service
mysqld
start用root登录mysql，为同步数据创建新帐号：grant
file,select,replication
slave
on
*.*
to
'test'@'%'
identified
by
'123456';------------------------备服务器配置-------------------------编辑配置文件：vi
/etc/my点吸烟 f在[mysqld]下加入：server-id=2master-host=192.168.3.1master-user=testmaster-password=123456master-port=3306#replicate-do-db=test
#此配置项为设置仅同步的数据库名，其它数据库忽略（建议不设置此选项）保存并启动mysql即可。如果需要查看同步状态，可分别在主从服务器上用如下命令查看：主服务器：show
master
status;从服务器：show
slave
status\G------------------值得说明的两个文件-----------------备份服务器上的/var/lib/mysql/目录下有两个：master.info和relay-log.info它们记录了主服务器的配置信息和同步信息，如果出现备份服务器不能同步数据的问题，可尝试将这两个文件删除，让备服务器重新同步。备注：进行操作之前先备份下数据比较保险一点。
先在主数据库中创建新数据库rep_test。
然后编辑主数据库的my.ini文件
在[mysqld]节点中增加如下内容：
server-id=1
#指定唯一的ID，1至32，必须的
log-bin=mysql-log-bin
#指定二进制日志存放路径，必须的
binlog-do-db=rep_test
#指定要同步的数据库，必须的
#binlog-ignore-db=mysql
#指定不要同步的数据库，如果指定了binlog-do-db就不用再指定该项
重启主数据库，然后在主数据库中建立一个备份账户
mysqlgrant
replication
slave
on
*.*
to slave@192.168.1.128
identified
by
'slave'
;
mysqlflush
privileges;
PS:identified
by
指定的slave是账号slave@192.168.1.128
的密码
显示主服务器的状态信息，并且找到File
和
Position
的值记录下来；
mysqlshow
master
status;
在从数据库中创建新的数据库rep_test。
然后编辑从数据库的my.ini文件
在[mysqld]节点中增加如下内容：
server-id=2
#指定唯一的ID，2至32，必须的，并且不能跟主数据库一样
replicate-do-db=rep_test
#指定要同步的数据库，必须的
#replicate-ignore-db=mysql
#指定不要同步的数据库，
重启从数据库，设置登录主数据库的账号和密码等信息，然后启动slave
mysqlchange
master
to
master_host='192.168.1.2',master_user='slave',master_password='slave',
master_log_file='mysql-bin.000002',master_log_pos=120;
mysqlstart
slave;
查看从数据库的信息
mysqlshow
slave
status
\G;
如果出现： Slave_IO_Running:
YesSlave_SQL_Running:
Yes以上两项都为Yes，那说明没问题了
测试主从复制是否有效果
在主数据库中创建一个新的数据库，然后再切换到从数据库查看是否同样多出通名的数据库
配置旧数据库的主从复制
如果一开始数据库的架构不是主从复制，并且运行一段时间后已经有数据存在，那配置的方式略有不同。
编辑主数据库的my.ini文件，加上一下内容：
binlog-do-db=landclash
重启主数据库，然后在主数据库中锁定所有的表
mysqlflush
tables
with
read
lock；
显示主服务器的状态信息，并且找到File
和
Position
的值记录下来；
mysqlshow
master
status;
将主数据库data目录下需要做主从复制的数据库的同名目录拷贝到从数据库的data目录下
编辑从数据库的my.ini文件，加上一下内容：
replicate-do-db=landclash
重启从数据库，因为主数据库在重新配置my.ini后，日志文件变成新的文件，所以需要再次设置登录主数据库的账号和密码等信息
mysqlstop
slave;
mysqlchange
master
to
master_host='192.168.1.2',master_user='slave',master_password='slave',
master_log_file='mysql-bin.000003',master_log_pos=120;
mysqlstart
slave;
再次输入查看从数据库状态的命令
mysqlshow
slave
status
\G;
完成上述配置后，回到主数据库，将表解锁
mysqlunlock
tables;
之后在主数据库的修改就能同步到从数据库上了。
