首先主从复制是什么？简单来说是让一台MySQL服务器去复制另一台MySQL的数据，使两个服务器的数据保持一致。
今天早上来到公司，遇到了一个主从复制的报错问题，虽然解决的过程比较快，但是我感觉还是有一定的借鉴意义，遇到类似的错误code，大家可以参考一下：
之前遇到的一个主从复制的报错问题，虽然解决的过程比较快，但是我感觉还是有一定的借鉴意义，遇到类似的错误code，大家可以参考一下：
1. 案例模拟 原理啥的原文已介绍，此处不再赘述，只是直接进行案例模拟。 1.1 修改参数 从库上查看 mysql> select Heartbeat from mysql.slave_master_info; +-----------+ | Heartbeat | +-----------+ | 5 | +-----------+ 1 row in set (0.00 sec) 从库上修改 /** 先查看slave_net_timeout参数 */ mysql> show vari
TA想问：在这样的场景下，还有办法让B库尽快跑完这7200秒延迟数据吗，或者正确的办法是什么呢？
状况描述： 今天登录一个MySQL数据库slave节点主机发现/var/lib/mysql下存放大量的mysql-relay-bin文件，最早的文件创建日期甚至是2018年，我记得在slave库同步完master的日志操作记录后，会删除这些文件（默认设置不会删除，我记错了），于是便查看了slave库的状态，发现如下报错：
MySQL Replication是MySQL非常重要的特性。用好了，可以发挥很大的作用，做负载均衡，做读写分离，做备份等等，能在关键时刻救DBA一命；用不好，那就是给DBA自己找麻烦了，处理不尽的故障。所以我这边给大家分享两个关于复制的案例。
mysql主从复制是最常见的高可用方式，通过主-从的方式，实现系统的高可用。在生产环境种，通常采用一主多从的方式，通过主库写数据，从库读数据，来提升系统的性能。 现在就演示一下，mysql5.7之下，如何配置主从复制。
在测试环境开启GTID运行一年多之后，我们准备近期上线生产。为了保证GTID顺利的上线，在测试环境模拟各种故障场景，观察GTID 的表现
在讨论从库之前，首先，主库的不合理设置同样会在一些情况下造成从库发生复制故障，所以主库得需要是双1的。 非双1有很可能造成从库比主库多事务，所以从库异常是比较容易发生的事情。
线上有一台服务器上，里面有一个mysql数据库服务，其实库也很小，就几个G，一直以来是保留了多天的备份集，但是因为业务的关系，这个库其实只有一些 基本的数据查询，但奇怪的是没有从库，一直以来是每天都会备份，保留了近一周的备份集，这种情况也倒相安无事。不过不巧的是这台服务器上还部署有 Oracle数据库，空间要大很多，随着业务的增长，这个数据量就上去了，结果空间的使用是越来越紧俏。保留一周的备份集，空间是越来越紧张。所以在一台 Oracle的备库机器上使用gtid创建了一个mysql从库。这种情况基本可以满足
在上一期《时区信息记录表|全方位认识 mysql 系统库》中，我们详细介绍了mysql系统库中的时区信息记录表，本期我们将为大家带来系列第七篇《复制信息记录表|全方位认识 mysql 系统库》，下面请跟随我们一起开始 mysql 系统库的系统学习之旅吧！
在单线程复制的情况下，5.7和5.6开关GTID的crash-safe其实可以简单理解为“没有差别”：
今天下午，线上阿里云RDS的本地只读从库宕机了，还好，这个个服务器上的数据库实例只是提供了一部分的读需求，很快就复原了，但是上面所有的数据库实例都down掉了，启动实例并保证主从复制关系迫在眉睫。这个过程中发现有一个主从复制的问题值得研究一下，虽然最后我解决了，但是具体的原因没有找到，还请大家帮忙看看，也算是集思广益了，如果某一天找到原因了，再回来更新一下。
因为实际的业务需求最近就需要部署一些MySQL服务器，而在部署mysql服务器中在做主从同步时用的都是MySQL Replication的主从同步的方法，当然实现mysql主从同步的方法还有很多，这里就只说使用MySQL Replication的主从同步的功能，在实现mysql的主从同步的常用的2种配置方式，当然可以根据实际的生产环境选择不同的方式，在这里就简单的把2种配置方法配置my.cnf说一下，因为以前有写过mysql的主从同步方法，这里就不再赘述了，需要可以参看：http://www.linuxidc.com/Linux/2017-02/140454.htm，这里为方便就用以上为例子
MySQL最常用的架构就是主从复制了，其实主从复制有很多选项，特别是在从库端，我们可以设置复制过滤，比如说忽略某张表或某个库。这些过滤选项都是可以在线修改而不用重启的。原来对这块了解不多，最近看了下相关资料，个人觉得这个功能还是很方便的，本篇文章会将这块内容分享给大家。
安装参考：http://www.cnblogs.com/007sx/p/7083143.html
1062错误----主键冲突，出现这种情况就是从库出现插入操作，主库又重新来了一遍，iothread没问题，sqlthread出错
今天主要聊一下MySQL的异步复制、全同步复制与半同步复制，目前我们生产库实际上用的就是异步复制了，后面再转成半同步复制。
MySQL的复制功能是构建基于MySQL的大规模、高性能应用的基础。复制功能不仅有利于构建高性能的应用，同时也是高可用性、可扩展性、灾难恢复、备份以及数据仓库等工作的基础。
1594这个错误看起来挺严重的，会提示你binlog文件或者Relay log损坏了,例如binary log is corrupted、relay log is corrupted之类的看起来很吓人是吧，多数是由于掉电引发的，这也说明了机房配备UPS的重要性。本文来自真实生产案例，感谢网友加内特提供，本人加以故障重现校验。一起来看下如何解决吧。
中继日志（relay log）只在主从服务器架构的从服务器上存在。从服务器（slave）为了与主服务器(Master)保持一致，要从主服务器读取二进制日志的内容，并且把读取到的信息写入本地的日志文件中，这个从服务器本地的日志文件就叫中继日志。然后，从服务器读取中继日志，并根据中继日志的内容对从服务器的数据进行更新，完成主从服务器的数据同步。
MySQL数据库主从复制在缺省情况下从库的relay logs会在SQL线程执行完毕后被自动删除，但是对于MHA场景下，对于某些滞后从库的恢复依赖于其他从库的relay log，因此采取禁用自动删除功能以及定期清理的办法。对于清理过多过大的relay log需要注意引起的复制延迟资源开销等。MHA可通过purge_relay_logs脚本及配合cronjob来完成此项任务，具体描述如下。
还有一个 半同步复制，他在协议中添加了一个同步步骤，这意味着 主节点在提交时需要等待从节点确认它已经接收到事务。只有这样，主节点才能继续提交操作。
此配置是我在使用过程中总结出比较实用的配置参数，基于GTID的主从复制场景中使用：
主从复制技术在MySQL中被广泛使用，主要用于同步一台服务器上的数据至多台从服务器，可以用于实现负载均衡，高可用和故障切换，以及提供备份等等。MySQL支持多种不同的复制技术，诸如单向，半同步异步复制等以及不同级别的复制，诸如数据库级别，表级，跨库同步等等。本文简要描述了一个基本的主从复制并给出示例。
二进制日志文件并不是每次写的时候都会同步到磁盘，当发生宕机的时候，可能会有最后一部分数据没有写入到binlog中，这给恢复和复制带来了问题。当sync_binlog=1表示每写缓冲一次就同步到磁盘，表示同步写磁盘的方式来写binlog。也就是说每当向MySQL提交一次事务，MySQL将进行一次fsync之类的磁盘同步命令来将binlog_cache的数据强制刷到磁盘中sync_binlog的值默认为0，sync_binlog=0时表示采用操作系统机制进行缓冲数据同步。采用sync_binlog=1时，会增加磁盘IO的次数，会影响写入性能。sync_binlog=1时，并不是100%安全，会存在相应的问题。比如说使用Innodb引擎时，在一个事务发出commit前，会将binlog立即刷到磁盘中。如果这时候已经写入到binlog中，但是还没有提交就已经挂了，那么MySQL重启时，会将通过Redo log、Undo log将这个事务回滚掉，但是binlog已经记入了该事务信息，不能回滚掉。所以我们需要设置innodb_support_xa=1确保MySQL服务层的binlog和MySQL存储引擎层的Redo log、Undo log之间的数据一致性。
1032错误----现在生产库中好多数据，在从库误删了，生产库更新后找不到了，现在主从不同步了，再跳过错误也没用，因为没这条，再更新还会报错
读写分离,简单地说是把对数据库的读和写操作分开,以对应不同的数据库服务器。主数据库提供写操作，从数据库提供读操作，这样能有效地减轻单台数据库的压力。
在 MySQL 系统中，有着诸多不同类型的日志。各种日志都有着自己的用途，通过分析日志，我们可以优化数据库性能，排除故障，甚至能够还原数据。这些不同类型的日志有助于我们更清晰的了解数据库，在日常学习及运维过程中也会和这些日志打交道。本节内容将带你了解 MySQL 数据库中几种常用日志的作用及管理方法。
1）主服务器将所有数据和结构更改记录到二进制日志中。 2）从属服务器从主服务器请求该二进制日志并在本地应用其内容。 3）IO：请求主库，获取上一次执行过的新的事件，并存放到relaylog 4）SQL：从relaylog中将sql语句翻译给从库执行
早上7点多接到一个数据库服务器空间报警，磁盘空间不足。登陆数据库查看，MySQL slave 大量延迟，有68G 的relay log。查看slave status 发现Relay_Log_Pos ,Exec_Master_Log_Pos 位点始终不变。
1、修改MySQL配置： 主库配置 server-id = 3 binlog-do-db=xmcp_gxfc #the db need to sync binlog-ignore-db = mysql #不需要同步的数据库 binlog-ignore-db = redmine #不需要同步的数据库 log_slave_updates = 1 binlog_format=mixed relay_log = /usr/local/mysql/relay_log/mysql-relay-bin read_only = 1
当master服务器上的数据发生改变时(增、删、改)，则将其改变写入二进制binlog日志中；slave服务器会在一定时间间隔内对master二进制日志进行探测其是否发生改变，如果发生改变，则开启一个I/O 线程请求master二进制事件，同时主节点为每个I/O线程启动一个dump线程，用于向其发送二进制事件，并保存至从库本地的中继日志中，从库(从节点)将启动SQL线程从中继日志中读取二进制日志，在本地重放，使得其数据和主节点的保持一致，最后IO线程和SQL线程将进入睡眠状态，等待下一次被唤醒。
MySQL支持单向、异步复制，复制过程中一个服务器充当主服务器，而一个或多个服务器充当从服务器
还有一个半同步复制，他在协议中添加了一个同步步骤，这意味着主节点在提交时需要等待从节点确认它已经接收到事务。只有这样，主节点才能继续提交操作。
一、角色划分 1、MySQL数据库规划 我现在的环境是：zhdy04和zhdy05已经做好了主主架构配置，现在需要的是把两台或者多台从服务器与主一一同步。 如果搭建主主环境，参照此链接！ 主机名 IP 地址 角色 Mysql_server_id zhdy04 192.168.230.145 masterA 145 zhdy05 192.168.230.146 masterB 146 zhdy06 192.168.230.147 slaveA 147 zhdy07 192.168.230.148 slaveB
所有的关系型数据库都存在一个通病性能差，在企业中如果用户量特别打，将所有的数据都存放在一台服务器上，其性能时远远达不到要求的。所以需要使用一些手段来解决其性能的问题。 提升性能的方式有向上扩展以及向外扩展 向上扩展(Scale Up):使用更新更好的硬件，但硬件在怎么更新也有其性能的极限。盲目的向上扩展无法结局根本的问题 向外扩展(Scale Out):就是使用多台机器分摊压力来提供服务
Mysql中有一种日志叫做bin日志（二进制日志）。这个日志会记录下所有修改了数据库的SQL语句（INSERT,UPDATE,DELETE,ALTER TABLE,GRANT等等）。
MySQL的日志类型很多，而每种类型都有着特殊的作用，了解这些日志，有助于我们更好地理解MySQL数据库的体系，进而更合理地使用数据库。
其实就是主要看 Slave_IO_Running 和 Slave_SQL_Running 两个线程的状态。
笔记写了不少，有时候有的朋友问我几个关键字，我就会从脑海里进行搜索，凡是写过的，搜索一下总能找到，帮助了别人，提高了自己，何乐而不为。 但是笔记写了很多，如果不加以改进，那么进步还是很小的，尤其比较怕的就是如果写出了问题的解决方案，但是这个解决方案是非主流的方式，可能有一 些潜在风险的，如果误导了读者，那就是罪过了。所以有时候想集中纠正一下。而且有时候看看以前写的文章，有时候会发现有一些分析思路可能在经历了大批量的 故障处理之后，思路可能会更开阔，这些其实也可以改进改进。 写笔记能坚持到现在
随着应用业务数据不断的增大，应用的响应速度不断下降，在检测过程中我们不难发现大多数的请求都是查询操作。
STATEMENT模式（SBR） 每一条会修改数据的sql语句会记录到binlog中。优点是并不需要记录每一条sql语句和每一行的数据变化，减少了binlog日志量，节约IO，提高性能。缺点是在某些情况下会导致master-slave中的数据不一致(如sleep()函数， last_insert_id()，以及user-defined functions(udf)等会出现问题)
我们知道，mysql数据库，为了得到更高性能，一般会读写分离，主库用于写操作，比如用于执行insert，update操作，从库用于读，也就是最常见的select操作。像下面这个图这样。
最近免费试用了一下云服务器，然后在两台服务器上安装了Mysql并搭建了主从同步数据库。mysql数据库的安装，大家可以去查看我的另一篇博客文章，下面为大家介绍搭建步骤及原理。原理 my
松信嘉範： MySQL/Linux专家 2001年索尼公司入职 2001年开始使用oracle 2004年开始使用MySQL 2006年9月-2010年8月MySQL从事顾问 2010年-2012年 DeNA 2012年~至今 Facebook
版权声明：本文为耕耘实录原创文章，各大自媒体平台同步更新。欢迎转载，转载请注明出处，谢谢
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
