注:使用docker部署mysql实例,方便快速搭建演示环境。但本文重点是讲解主从配置,因此简略描述docker环境构建mysql容器实例。
公司运维能力不是太好,数据库最近出了一次问题,导致丢失了一天的数据,并且某个服务宕机一晚上。为了避免再次出现类似问题,我决定添加一个Slave服务器,以避免数据丢失和服务宕机的问题。
前两天 MTSC 2018 在北京国际会议中心圆满召开,并取得非常好的反响,虽然临时有事,没去成,但还是非常赞许为此会议付出的朋友和小伙伴们~
今天早上来公司,查看一个5.5版本的MySQL主从复制的架构的时候,发现一个问题,这个问题之前在5.7版本的MySQL版本中没有遇到过,这里记录一下,以供大家参考。
前一段时间客户反馈复制报错 1236 ,根据报错提示该报错为从库读取到了主库不存在的 binlog 日志,导致复制中断,报错截图如下,需要帮忙分析为什么会报错 Could not open log file 原因。
MySQL复制全解析 Part 2 一步步搭建基于二进制文件位置的MySQL复制
数据对于我们来说是一项最重要的资产,因为数据丢失带来的损失,对于一家公司来说,有时也是毁灭性的。
https://dev.mysql.com/doc/refman/5.7/en/replication.htm
首先主从复制是什么?简单来说是让一台MySQL服务器去复制另一台MySQL的数据,使两个服务器的数据保持一致。
虽然从库可以不需要开启二进制日志功能,这里我们推荐主从库同时开启二进制日志功能,方便主从切换
从上图可以看出,首先管理节点发现MySQL服务挂掉,之后调用masterha_secondary_check脚本分别从另外2个从库检查主库,发现也无法连接
Q:为啥要引入主从同步机制? A:防止业务数据库突然宕掉,不能快速的恢复业务正常运行,有利于数据库架构的健壮性,提升访问速度,方便运维保证的数据物理安全(容灾备份);
Zabbix监控Mysql | Mysql 5.7,8.0基准性能比较,Mysql8.0主主配置
之前部署了Mysql主从复制环境(Mysql主从同步(1)-主从/主主环境部署梳理),在mysql同步过程中会出现很多问题,导致数据同步异常。 以下梳理了几种主从同步中可能存在的问题: 1)slave运行过慢不能与master同步,也就是MySQL数据库主从同步延迟 MySQL数据库slave服务器延迟的现象是非常普遍的,MySQL复制允许从机进行SELECT操作,但是在实际线上环境下,由于从机延迟的关系,很难将读取操作转向到从机。这就导致了有了以下一些潜规则:“实时性要求不高的读取操作可以放到slave服
当master服务器上的数据发生改变时(增、删、改),则将其改变写入二进制binlog日志中;slave服务器会在一定时间间隔内对master二进制日志进行探测其是否发生改变,如果发生改变,则开启一个I/O 线程请求master二进制事件,同时主节点为每个I/O线程启动一个dump线程,用于向其发送二进制事件,并保存至从库本地的中继日志中,从库(从节点)将启动SQL线程从中继日志中读取二进制日志,在本地重放,使得其数据和主节点的保持一致,最后IO线程和SQL线程将进入睡眠状态,等待下一次被唤醒。
1)主服务器将所有数据和结构更改记录到二进制日志中。 2)从属服务器从主服务器请求该二进制日志并在本地应用其内容。 3)IO:请求主库,获取上一次执行过的新的事件,并存放到relaylog 4)SQL:从relaylog中将sql语句翻译给从库执行
-master_state=alive 代表告诉MHA原master还是存活的,不需要将其从配置文件删除
主从配置其实蛮简单的,主从配置也叫热备,热备就是在数据库启动的情况下实时对数据进行备份,相反对概念叫冷备,就是在数据库停止对时候对数据进行备份。
本文使用MySQL原生支持的主从同步机制,详细记录了配置步骤及运维操作方法,可供大家直接参考、使用。
Mysql主从同步,要求需要先搭建至少两个mysql实例,一主一从,使用推荐Docker搭建Mysql《Docker部署安装Mysql》
复制状态信息查看可以通过一些语句如(show slave status)和相关的系统表来进行查看,它们之前有对应的关系
然后set global sql_slave_skip_counter = 1;跳过一步错误
我们的项目采用了读写分离的方案:查询和更新的业务走主库,统计相关的功能走从库,从而减少主库的压力。原理如下图所示:
在前面基础功能实现的过程中,我们后台管理系统及移动端的用户,在进行数据访问时,都是直接操作数据库MySQL的。结构如下图:
我们知道,mysql数据库,为了得到更高性能,一般会读写分离,主库用于写操作,比如用于执行insert,update操作,从库用于读,也就是最常见的select操作。像下面这个图这样。
爱可生 DBA 团队成员,负责项目日常问题处理及公司平台问题排查。热爱互联网,会摄影、懂厨艺,不会厨艺的 DBA 不是好司机,didi~
1、在业务复杂的系统中,有这么一个情景,有一句sql语句需要锁表,导致暂时不能使用读的服务,那么就很影响运行中的业务,使用主从复制,让主库负责写,从库负责读,这样,即使主库出现了锁表的情景,通过读从库也可以保证业务的正常运作
"ERROR 3021 (HY000): This operation cannot be performed with a running slave io thread; run STOP SLAVE IO_THREAD FOR CHANNEL '' first."
原因:1.数据安全问题,如果你将数据存贮在容器中,当容器rm后,你就无了,当然你可以使用外挂数据卷的方式,但我在某些大佬的文章上看到,即使你外挂的数据卷,docker volumes的设计是围绕union fs镜像层提供持久化存贮,如果容器异常崩溃,数据库未正常关闭,则可能损坏数据,而且外挂数据卷对物理机硬件损伤较大(这段话是我从大佬文章里抄的,但前面rm数据就不见了是我实践过的)
随着网站访问和请求量的增加,单台数据库服务器的连接已耗尽,会出现连接请求还在等待,或是数据库服务器崩溃等现象,这时候我们考虑如何减少数据库的连接,可以通过优化代码、使用缓存、数据库读写分离等方式解决此问题。 什么是读写分离:将数据库的读、写操作分别作用到不同的数据库(不同物理机)上。 适用场景:读操作远大于写操作,包含大量复杂统计、离线计算等任务(比如定时按各维度对数据进行统计分析,或者结算佣金等) 研究了一阵,在配置的过程中出现各种问题。。今天刚配置好 windows系统环境:本机+VM虚拟机:MySql5.6,先安装好MySql 找到MySql5.6的 my.ini配置文件,在 C:\ProgramData\MySQL\MySQL Server 5.6目录中,ProgramData文件夹默认是隐藏的 Mysql主从同步的现实: 1、Master库将变更记录到binlog中 2、Slave将master的binlog拷贝到它的relay log(中继日志)中 3、slave重做中继日志中的事件 可以通过中间价实现读写分离,如Ameba,Corba,mysql-Proxy(官方)
1、做数据的热备,作为后备数据库,主数据库服务器故障后,可切换到从数据库继续工作,避免数据丢失。
注意:此方案中master_log_file和master-log_pos也和slave中一样,指向主库。
注意server-id必须是一个唯一的数字,必须主从不一致, 且主从库必须设置项。
主从复制:主库master将DDL,DML操作写入二进制文件binlog,从库通过IO-thread将binlog转换为中继日志relaylog,并且通过sql-thread从relaylog读取数据,重新释放数据记录变化并反应到自身数据来达到主从同步
注意 server-id必须是一个唯一的数字,必须主从不一致, 且主从库必须设置项。
在了解主从复制之前必须要了解的就是数据库的二进制日志(binlog),主从复制架构大多基于二进制日志进行。
参考https://www.cnblogs.com/xiaoyuanqujing/articles/11796376.html#4417022
①当Master节点进行insert、update、delete操作时,会按顺序写入到binlog中。
例如:如果使用 Navicat、PHPMyAdmin 之类的可视化工具,可以直接点击转储 SQL 文件,或者导出 SQL 文件之类的功能。
在了解主从复制之前必须要了解的就是数据库的二进制日志(binlog),主从复制架构大多基于二进制日志进行,二进制日志相关信息参考:http://www.cnblogs.com/clsn/p/8087678.html#_label6
网上也经常看到一些段子,某公司程序员对工作不满,删库跑路,老板损失惨重,欲哭无泪。这不最近又爆出一例,京东到家程序员离职当天删库跑路!
由于mysql主从复制是基于binlog的一种异步复制 通过网络传送binlog文件,理所当然网络延迟是主从不同步的绝大多数的原因,特别是跨机房的数据同步出现这种几率非常的大,所以做读写分离,注意从业务层进行前期设计。
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
还有一个 半同步复制,他在协议中添加了一个同步步骤,这意味着 主节点在提交时需要等待从节点确认它已经接收到事务。只有这样,主节点才能继续提交操作。
主从复制是指将主数据库的DDL和DML操作通过二进制日志传到从服务器中,然后在从服务器上对这些日志重新执行也叫重做,从而使得从数据库和主库的数据保持同步。
还有一个半同步复制,他在协议中添加了一个同步步骤,这意味着主节点在提交时需要等待从节点确认它已经接收到事务。只有这样,主节点才能继续提交操作。
领取专属 10元无门槛券
手把手带您无忧上云