在实际的生产中,为了解决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;
之后在主数据库的修改就能同步到从数据库上了。