本文使用MySQL原生支持的主从同步机制，详细记录了配置步骤及运维操作方法，可供大家直接参考、使用。
今天一位跨界老码农不知咋回事，兴奋过了头，一不小心把数据库给删掉啦，然后问我咋恢复，然后我告诉他基于 binlog 可以恢复，谁成想没有开启 binlog，最后只能躲在角落里伤心。
MySQL binlog日志记录了MySQL数据库从启用日志以来所有对当前数据库的变更。binlog日志属于二进制文件，我们可以从binlog提取出来生成可阅读的SQL语句来重建当前数据库以及根据需要实现时点恢复或不完全恢复。本文主要描述了如果提取binlog日志，并给出相关示例。
项目新上线一个月，qa需要测试断电服务拉起，服务拉起成功后，发现mysql主从异常
删库跑路也是个老梗了，可见在运维数据库的过程中误删除数据，或者开发的代码有bug，造成数据的误删除屡见不鲜。不过现在也有许多用于恢复或预防误删除的方案，例如SQL管理系统，将要执行的SQL先交由管理员审核，然后由管理员备份一个镜像数据库，在镜像上执行该SQL，并在执行后还原镜像。这样经过层层把关就可以大大减小出现误操作的几率。
把自己伪装成slave，从源master解析binlog并入库target MySQL端。
正常返回: Slave_IO_Running: Yes Slave_SQL_Running: Yes
声明： 如果您有更好的技术与作者分享，或者商业合作； 请访问作者个人网站 http://www.esqabc.com/view/message.html 留言给作者。 如果该案例触犯您的专利，请在这里：http://www.esqabc.com/view/message.html 留言给作者说明原由， 作者一经查实，马上删除。
MySQL的日志有主要有四种，会记录不同的操作行为，分别是----二进制日志、错误日志、查询日志、慢查询日志。开启日志是MySQL安全的必要手段之一，但是会影响MySQL的性能，所以要学会日志管理，根据实际的业务需求来选择日志。
前一段时间客户反馈复制报错 1236 ，根据报错提示该报错为从库读取到了主库不存在的 binlog 日志，导致复制中断，报错截图如下，需要帮忙分析为什么会报错 Could not open log file 原因。
* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。 一、前提 在一套非常老的系统上，有一套GreatSQL主从集群（1主1从），主从复制采用的是FILE+POS方式复制，磁盘使用紧张需要扩容，只能在该台机器上添加更大的磁盘，将原数据盘替换，也没有其他的机器资源替换。这套系统没有VIP，没有高可用切换工具，业务读写直连主节点，从节点可供读，允许有一定的延迟，全程磁盘扩容需要手动操作，以下方案步骤是模拟最快的方式去进行磁盘扩容。 二、整体思路是 在主节点机器上挂载一块新磁盘，在新磁盘上搭建一个新的从节点，旧从节点的主变为新从节点，最后将主节点与新从节点准备好配置文件后，关闭主节点，将新从节点使用新的配置文件重启，端口号为旧主port，新主实例顶替旧主成功。 三、模拟环境 主从架构 db01:master，172.17.135.81:3306 db02:slave02，172.17.134.225:3306 原主从db01 master复制数据到db02 slave02，现在在db01上搭建新的从节点slave01，并将slave01提升为新的主节点master02 db01：IP为172.17.135.81 master ：port 3306 slave01：port 3307 db02：IP为172.17.134.225 slave02：port 3306 四、以下操作为模拟切换流程 1）.在db01上master 数据放在磁盘 /data/ 使用xtrabackup工具备份并搭建db01 slave01 数据放在磁盘/data2/上 2）.改变db02 slave02 数据源为 db01 slave01（即db02 slave02 从db01-slave01同步数据），后期切换数据库 操作过程 01.停掉db02 slave02 复制线程 先停slave02目的是，slave02获取执行的binlog比db01 slave01上的binlog少，方便后续db02 slave02 追数据到db01 slave01 指定的位点
今天还是说说级联复制的问题情况，因为架构做了调整，我们要删除其中的一个中继节点（新加坡节点），而直接使用北京节点去连接北美的节点。 更多的信息可以参考。 MySQL级联复制中的数据同步(r11笔记第2
查看master状态，即最后一个binlog日志的编号名称，及其最后一个操作时间pos结束点值
首先主从复制是什么？简单来说是让一台MySQL服务器去复制另一台MySQL的数据，使两个服务器的数据保持一致。
Mysql主从同步，要求需要先搭建至少两个mysql实例，一主一从，使用推荐Docker搭建Mysql《Docker部署安装Mysql》
#binlog format有三种形式：Statement、Mixed、Row，默认设置为mixed
写第一篇，意味着还有第二篇的内容，这个也是自己今天偶然发现的问题。同事之前碰到了一个MySQL服务不断重启的问题，究其原因，其实倒还合理，今天的这个问题比较纠结，看起来好像没有直接的联系，问题算是比较诡异。 我简单复现下这个问题，我在5.7.19的版本中做了测试，可以复现。 首先搭建一主两从的测试环境，使用sandbox或者是我自己写的shell版本也可以，具体可以参考:https://github.com/jeanron100/mysql_slaves 我配置的环境如下，端口分别为10010
记录下File和Position的值 注意：执行完此步骤后不要再操作主服务器MySQL，防止主服务器状态值变化
1、MySQL5.6 数据库主从（Master/Slave）同步安装与配置详解请参考： http://blog.csdn.net/xlgen157387/article/details/51331244#comments
yuluo-mysql-master port: 3306 yuluo-mysql-slave1 port: 3307 yuluo-mysql-slave2 port：3308
mysql 复制是基于binlog日志的，binlog日志中根据事件类型，事件以不同的格式被记录到二进制日志中，复制的格式由系统变量binlog_format控制，mysql支持三种格式的binlog日志格式设置，各有优缺点：如下
uname命令用于打印当前系统相关信息（内核版本号、硬件架构、主机名称和操作系统类型等）。
从案例中我们得知是中途开启的GTID，但是留下了很多未开启GTID的BINLOG，从第六部分源码bool MYSQL_BIN_LOG::init_gtid_sets()函数的分析，我们知道删除BINLOG后也会触发正向查找来获取gtid_purged(Gtid_state.lost_gtids)。当读取到第一个BINLOG的时候虽然获取到了PREVIOUS GTID EVENT但是没有GTID EVENT，而simple_recovery=flase所以需要继续查找下一个文件，直到找到同时包含PREVIOUS GTID EVENT和GTID EVENT的 那个BINLOG才会停止，那么显然这种情况下那些GTID关闭的时候生成的BINLOG将会全部扫描一遍，如果量大那么代价将是巨大的。 而案例中每半个小时会触发一次BINLOG切换，因为触发超过expire_logs_days参数设置导致BINLOG进行删除，触发了大量的BINLOG扫描。 显然有了前面的基础这个案例很容易分析。
当开启mysql数据库主从时，会产生大量如mysql-bin.00000* log的文件，这会大量耗费您的硬盘空间。 如：
目前MySQL数据库最常用的是主从架构，大多数高可用架构也是通过主从架构演变而来。但是主从架构运行时间长久后容易出现数据不一致的情况，比如因从库可写造成的误操作或者复制bug等，本篇文章将会详细探究出现主从不一致及如何解决这种问题。
在mysql中,当发生数据变更时,都会将变更数据的语句,通过二进制形式,存储到binlog日志文件中.
CentOs7.3 搭建 MySQL 5.7.19 主从复制，以及复制实现细节分析 概念 主从复制可以使MySQL数据库主服务器的主数据库，复制到一个或多个MySQL从服务器从数据库，默认情况下，复制异步; 根据配置，可以复制数据库中的所有数据库，选定的数据库或甚至选定的表。 MySQL中主从复制的优点 横向扩展解决方案 在多个从库之间扩展负载以提高性能。在这种环境中，所有写入和更新在主库上进行。但是，读取可能发生在一个或多个从库上。该模型可以提高写入的性能（由于主库专用于更新），同时在多个从库上读取，可以
配置mysql的主从模式，当一台mysql出现问题后，另外一台可以正常工作。 两台机器IP：192.168.1.60（master）、192.168.1.61（slave） 注意：在配置之前，确保两台节点都有需同步的数据库。 1、master节点配置 1.1、修改配置文件 192.168.1.60：master节点 vim /etc/my.cnf 添加如下内容： [mysqld] log-error=/data/mysql_log/error.log # mysql的error日志 log=
其实就是主要看 Slave_IO_Running 和 Slave_SQL_Running 两个线程的状态。
MySQL 的二进制日志 binlog 可以说是 MySQL 最重要的日志，它记录了所有的 DDL 和 DML 语句（除了数据查询语句select、show等），以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。binlog 的主要目的是复制和恢复。
MySQL集群具备高可用、可扩展、以管理、低成本的特点。生产环境中MySQL部署会使用Mysql 主从架构或Mysql双主互备架构。同时采用keepalived来实现mysql的自动故障切换。两台Mysql服务器互为主从，但同一时刻只有一个Mysql服务器可读写，另一个Mysql服务器只能进行读操作，保证数据的一致性。MySQl主主同步就是两台机器互为主的关系，在任何一台机器上写入都会同步至备端。
今天是《MySQL核心知识》专栏的第16章，今天为大家系统的讲讲MySQL中的日志，希望通过本章节的学习，小伙伴们能够举一反三，彻底掌握MySQL中日志相关的知识。好了，开始今天的正题吧。
之所以有这样一篇文章，是因为在前几天的一个晚上，要下班的时候，业务方忽然有一个需求，是需要恢复一个表里面的数据，当时问了下情况，大概是这样的：业务方不小心在一个表里面做了一个update的操作，可能是where条件没有写对，导致表里面的数据被写坏了，但是数据目前还没有落盘，只是在内存中的值修改了，现在要求恢复到之前的数据。万幸，这份数据是平台上某些商品的价格，基本上是有限个商品，然后价格值也都是固定的，之前有对这个价格表进行备份，于是给他直接重新导入了一份价格表的数据，这个问题也算是解决了。
这是很早时候写的一篇文章，今天翻看历史文章的时候发现的，觉得还是有收获，就分享出来了。以下是文章原文：
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/xmt1139057136/article/details/88840293
为了保证高可用，之前在测试环境部署了一套 MySQL 双主模式，当一个主库服务出现异常，可以将流量切到另外一个主库，两个主库之间相互同步数据。
PT工具在MYSQL中的使用其实已经好像有“半个世纪了”，其出名的原因主要是因为pt-osc，如果你不知道，那你真的用过MYSQL，其实还有另外两家 FB-OST , GH-OST.
Xtrabackup是Percona公司开发的一款开源的MySQL热备份工具，之前的工作中也是经常使用，但是也仅仅是停留在使用的阶段，对于这个工具的细节，并没有做过多的研究，今天细细看了一下过程，还是有点收获的，写下来记录一下，有不对的地方，还请指正。
对于任何一个企业来说，数据安全的重要性是不言而喻的。我在开篇词中也曾经强调过，凡是涉及到数据的问题，都是损失惨重的大问题。
（1） 错误日志log_error：记录MySQL服务的启动、运行或停止MySQL服务时出现的问题
https://mp.weixin.qq.com/s/XSnFkuYzIlGWMaXIl-oPeQ
近期研究了下MySQL的半同步复制机制，想要体验一下。搭建环境是件麻烦事，然后就想到用Docker快速搭建环境。
canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议 MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal ) canal 解析 binary log 对象(原始为 byte 流)
MySQL服务器的主从配置，本来是一件很简单的事情，无奈不是从零开始，总是在别人已经安装好的mysql服务器之上 ，这就会牵扯到，mysql的版本，启动文件，等一些问题。
1.mysql复制概念 指将主数据库的DDL和DML操作通过二进制日志传到复制服务器上，然后在复制服务器上将这些日志文件重新执行，从而使复制服务器和主服务器的数据保持同步。复制过程中一个服务器充当主服务器（master），而一个或多个其它服务器充当从服务器（slaves）。主服务器将更新重新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器、从服务器在日志中读取的最后一次成功更新的位置。从服务器接受从那时起发生的任何
grant replication slave,reload,super on *.* to'slave'@'192.168.1.101'identified by '123456'；
错误日志是MySQL中最重要的日志之一，它记录了当MySQL启动和停止时，以及服务器在运行过程中发生的任何严重错误时的相关信息，当数据库出现任何故障导致无法正常使用时，建议首先查看此日志
MYSQL 的错误日志的详细度其实不少人是忽略的,实际上MYSQL这边的关于告警和错误日志本身也是有一些注意的地方.
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
