这一般是数据库的安全策略,对于一些安全性要求比较高的系统,数据库通常是由主服务器和备份服务器组成,主备同时运行,主服务器有数据改动后,立刻会同步到备份服务器。所以在日常运维工作中,为了防患于未然,经常会进行主备切换,就是把生产对接的服务器从主数据库切换到备份库上,使用备份库运行一段时间,看看备份库运行是否正常,数据是否正确等。
镶黄网站制作公司哪家好,找创新互联公司!从网页设计、网站建设、微信开发、APP开发、成都响应式网站建设公司等网站项目制作,到程序开发,运营维护。创新互联公司公司2013年成立到现在10年的时间,我们拥有了丰富的建站经验和运维经验,来保证我们的工作的顺利进行。专注于网站建设就选创新互联公司。
切换的操作只需将连接池中,数据库服务器的Ip换成备份库Ip就可以了。
一:环境
192.168.1.100 master
192.168.1.101 slave1
192.168.1.102 slave2
slave1,slave2都是连在master上。
二:模拟主故障
关闭master实例
service mysql stop
此时,slave1,slave2上show slave status\G都会发现错误:
Last_IO_Error: error reconnecting to master'RepUser@192.168.1.100:3307' - retry-time: 60 retries: 1
IO进程和sql进程状态:
Slave_IO_Running: Connecting(该状态表示会一直尝试重连主,如果主正常了,该进程状态会自动变成Yes)
Slave_SQL_Running: Yes
此时,master不能提供读写服务。我们想将其中最新的slave提升为主。
三:切换步骤
3.1确保所有的relay log全部读取完毕
在每个从库上执行:
stopslave io_thread;
showprocesslist;
直到看到Slave has read all relay log; waitingfor more updates,则表示从库更新都执行完毕了
或者通过show slave status查看
Slave_SQL_Running_State: Slave has read allrelay log; waiting for more updates
3.2 选择新的主库
对比选择Relay_Master_Log_File,Exec_Master_Log_Pos最大的作为新的主库,这里我们选择slave1为新的主库
其实,如果两个从IO进程一直都是正常,没有落后于主,且relay log都已经重放完成,两个从是一样的,选择哪个都可以。
这里选择slave1作为新主。
3.3 进行相应配置
登陆slave1,执行stop slave;
并进入数据库目录,删除master.info和relay-log.info文件(删除前,可以先备份下这俩文件);
配置my.cnf文件,开启log-bin,如果有log-slaves-updates=1和read-only=1则要注释掉,然后重启slave1.
3.4 reset master
在slave1上reset master,会重新生成二进制日志。
mysql reset master;
Query OK, 0 rows affected (0.02 sec)
mysql show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 154 |
+------------------+-----------+
1 row in set (0.00 sec)
3.5创建用于同步的用户
如果slave1完全同步master的话,这步可以省略。
3.6 slave2指向slave1
[sql] view plain copy
mysql change master to master_user='RepUser',master_password='beijing',master_host='192.168.1.101',master_port=3307,master_log_file='mysql-bin.000001',master_log_pos=154;
Query OK, 0 rows affected, 2 warnings (0.00 sec)
mysql start slave;
Query OK, 0 rows affected (0.00 sec)
3.7 将程序写IP改成slave1的IP
程序里之前记录的是master的IP,现在master宕机,故需改IP。
主从切换一般在如下情况下才进行,
1、例行的主库重启,主库运行一段时间后需要将主库进行重启扫盘,降低主库死机的风险
2、主库异常情况下切到从库。
3、分机房网络调整涉及到主库的情况。
你的情况要看宕掉后的情况。如果有期间同步延迟,需要另外进行处理。
在实际的生产中,为了解决Mysql的单点故障,一般都会采用「主备模式」。
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主备怎么切换 mysql主备切换原理
链接分享:https://www.cdcxhl.com/article34/hhgppe.html
成都网站建设公司_创新互联,为您提供品牌网站设计、App开发、外贸网站建设、营销型网站建设、搜索引擎优化、软件开发
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联