该问题来自某客户，据描述，他们在部署 MySQL 主从复制时，有时候仅在主库上创建复制用户，有时候主从实例上都会去分别创建复制用户，发现这两种方式都可以成功建立复制。针对这一现象，进行了一轮验证，来观察采用不同方式创建复制用户对主从复制的影响。
虽然从库可以不需要开启二进制日志功能，这里我们推荐主从库同时开启二进制日志功能，方便主从切换
2、登录mysql,创建mysql用户(或者使用已经存在的也行),并且给予只能进行主从同步
在前面基础功能实现的过程中，我们后台管理系统及移动端的用户，在进行数据访问时，都是直接操作数据库MySQL的。结构如下图：
目前MySQL数据库最常用的是主从架构，大多数高可用架构也是通过主从架构演变而来。但是主从架构运行时间长久后容易出现数据不一致的情况，比如因从库可写造成的误操作或者复制bug等，本篇文章将会详细探究出现主从不一致及如何解决这种问题。
爱可生华东交付服务部 DBA 成员，主要负责Mysql故障处理及相关技术支持。爱好看书，电影。座右铭，每一个不曾起舞的日子，都是对生命的辜负。
https://dev.mysql.com/doc/refman/5.7/en/replication.htm
在上篇文章中我们介绍了基于Docker的Mysql主从搭建，一主多从的搭建过程就是重复了一主一从的从库配置过程，需要注意的是，要保证主从库my.cnf中server-id的唯一性。搭建完成后，可以在主库 show slave hosts查看有哪些从库节点。
在上篇文章中我们介绍了基于Docker的MySQL主从搭建，一主多从的搭建过程就是重复了一主一从的从库配置过程，需要注意的是，要保证主从库my.cnf中server-id的唯一性。搭建完成后，可以在主库show slave hosts查看有哪些从库节点。
将从库上的数据库清空，并还原为普通的数据库，(删除master.info relay-log.info relay-bin.index)
MySQL复制全解析 Part 2 一步步搭建基于二进制文件位置的MySQL复制
例如：如果使用 Navicat、PHPMyAdmin 之类的可视化工具，可以直接点击转储 SQL 文件，或者导出 SQL 文件之类的功能。
（1）分析主库 mysql -uroot -p12345 -S /data/18251/mysqldata/mysql.sock < analyze_table.sql
需求来源是开发想把多个库放置到一个中心库中，实现统计分析的需求。因此就有了多主一从的构想，而mysql不提供这样的原生方案（最新的mysql版本支持，但是新版本谁敢用呢），只能通过几种变种来实现，以下是集中方案的介绍：
Mysql主从复制也可以称为Mysql主从同步，它是构建数据库高可用集群架构的基础。它通过将一台主机的数据复制到其他一台或者多台主机上，并重新应用日志（realy log）中的SQL语句来实现复制功能。Mysql支持单向，双向，链式级联，异步复制，复制过程中一台服务器充当主库（master），而一个或者多个服务器充当从库（slave）
一 主库手动复制至从库 1.1 Master主库锁表 1 mysql> flush tables with read lock; 2 Query OK, 0 rows affected (0.00 sec) 1.2 主库备份 1 [root@master ~]# mysqldump -uroot -p -B mydb > master.sql 说明：-B参数有建库语句。 1.3 从库导入数据库 1 [root@Slave01 ~]# mysql -uroot -padmin < master
在实际使用MySQL的时候我们有时要增加一些新的库进行主从同步，所以可以通过修改my.cnf文件以及在主库上添加用户连接权限就可以实现主从同步，而在做主从同步的时候碰到几个问题这里就和大家说一下，至于如何构建主从同步这里就不再多说了，相信在网上能找到一大堆，这里就稍稍提几个关键点,在从库下的my.cnf添加如下几行：
这里需要说的是如果你的IO线程状态为connecting或no可能证明你的防火墙有问题 查看一下防火墙规则，放行端口要不就把防火墙关闭 systemctl stop firewalld 关闭防火墙之后 docker restart mysql 当我要重启数据库的时候会报错iptables等一些报错 不要慌。。。不是啥大问题 重启一下docker systemctl restart docker.service 再次重启的时候就不会报错了
基础信息 主库: 数据库2 10.126.4.2 数据库3 10.126.4.3 1. 停止数据库3对外服务 防止同步过程中服务通过数据库3写入数据 $ firewall-cmd --remove-port=3306/tcp $ firewall-cmd --add-rich-rule="rule f amily="ipv4" source address="10.126.4.2" port protocol="tcp" port="3306" accept" $ firewall-cmd --rel
mysqldump -uroot -pwww.Mwbyd91@ -A -q --single-transaction --master-data=2 > /root/all.sql
我们通常会遇到这样的一个场景，就是需要将一个数据库的数据迁移到一个性能更加强悍的数据库服务器上。这个时候需要我们做的就是快速迁移数据库的数据。
GTID模式：GTID是事务的ID，唯一识别号，全局唯一。对于主从复制简单来说就是不需要管binlog日志和复制点，简化复制操作和降低复制集群维护的难度，但是只支持带事务的引擎和语句
MySQL主从同步是在MySQL主从复制(Master-Slave Replication)基础上实现的，通过设置在Master MySQL上的binlog(使其处于打开状态)，Slave MySQL上通过一个I/O线程从Master MySQL上读取binlog，然后传输到Slave MySQL的中继日志中，然后Slave MySQL的SQL线程从中继日志中读取中继日志，然后应用到Slave MySQL的数据库中。这样实现了主从数据同步功能。
依托前文的解析来讲5.7中 GTID带来的运维改变，我想理解应该是更加深刻，这节主要讨论以下几个部分：
使用云上的MySQL时，会遇到很多人询问CDB的 为了更好的了解云上的MySQL，本文将介绍一些重要的知识点。
主服务器和从服务器可以位于不同的网络拓扑中，还能对整台服务器、特定的数据库，甚至特定的表进行复制。
Mysql主从同步时Slave_IO_Running：Connecting ; Slave_SQL_Running：Yes的情况故障排除
使用MySQL 5.6，搭建主从复制。关于5.6的安装，可以参考《MySQL 5.6 rpm安装方法和碰见的问题》。
MySQL5.6加入了GTID的新特性，其全称是Global Transaction Identifier，可简化MySQL的主从切换以及Failover。GTID用于在binlog中唯一标识一个事务。当事务提交时，MySQL Server在写binlog的时候，会先写一个特殊的Binlog Event，类型为GTID_Event，指定下一个事务的GTID，然后再写事务的Binlog。主从同步时GTID_Event和事务的Binlog都会传递到从库，从库在执行的时候也是用同样的GTID写binlog，这样主从同步以后，就可通过GTID确定从库同步到的位置了。也就是说，无论是级联情况，还是一主多从情况，都可以通过GTID自动找到需要进行复制的点位，而无需像之前版本那样通过File_name和File_position来进行位置点的主从复制。
mysqldump --single-transaction --master-data=2 --triggers --routines --all-databases -uroot -p > all.sql
由于昨天是用了之前配置了主从的机器去测试，各种失败，最后不得不使用两个新建的虚拟机去测试，正好模拟新建一个环境，我就完完整整的搭建一遍~ 需求： 在企业中，数据库高可用一直是企业的重中之重，中小企业很多都是使用mysql主从方案，一主多从，读写分离等，但是单主存在单点故障，从库切换成主库需要作改动。因此，如果是双主或者多主，就会增加mysql入口，增加高可用。不过多主需要考虑自增长ID问题，这个需要特别设置配置文件，比如双主，可以使用奇偶，总之，主之间设置自增长ID相互不冲突就能完美解决自增长ID冲突问题。
“MySQL主从复制”技术在互联网行业常见高可用架构中应用非常广泛，例如常见的一主一从复制架构、keepalived＋MySQL双主（主从）复制架构、MHA＋一主两从复制架构等等都应用了MySQL主从复制技术。但因主从复制是基于binlog的逻辑复制，难免出现复制数据不一致的风险，这个风险不但会引起用户数据访问前后不一致的风险，而且会导致后续复制出现1032、1062错误进而引起复制架构停滞的隐患，为了及时发现并解决这个问题，我们需要定期或不定期地开展主从复制数据一致性的校验和修复工作，那么如何实现这项工作呢？又如何实现这项工作的自动化呢？我们来探讨这些问题。
set global bulk_insert_buffer_size=128*1024*1024;
最近负责了一起数据迁移的项目，因为机器硬件过保，因为资源存在冗余，因为。。。总之话还没说完，就得到了项目组的支持，所以迁移的需求是明确的。 那么涉及的服务器数量还真是不少，当然我只是列出来虚拟的图说明
MySQL主从同步集群在生成环境使用过程中，如果主从服务器之间网络通信条件差或者数据库数据量非常大，容易导致MySQL主从同步延迟。
然后set global sql_slave_skip_counter = 1;跳过一步错误
因为服务器迁移，目前一套硬件老化的MySQL主从服务器都需要替换为新服务器，总体评估了一下，在不改变版本的情况下，采用了较新的5.6子版本。就是如下图所示的左边和右边。 如果要做这个完整的切换，
在MySQL中，主从架构应该是最基础、最常用的一种架构了。后续的读写分离、多活高可用架构等大多都依赖于主从复制。主从复制也是我们学习MySQL过程中必不可少的一部分，关于主从复制的文章有很多，笔者也来凑凑热闹，写写这方面的内容吧，同时分享下自己的经验和方法。
主从复制原理图
https://downloads.mariadb.org/mariadb/10.3.16/
虽然MySQL5.7 的主从复制已经很稳定了，但在备库可读写的情况下，总是会出现部分数据不一致的情况，例如常见的1062、1032和1050错误。下面就介绍下这类报错的常见处理方法和常见主从复制结构的调整。 环境描述 一 1、mysql 5.7 以上， 2、binlog format 是row格式（5.7默认） 3、传统复制（生产强烈推荐使用gtid） 4、log-bin , log_slave_updates 开启 5、复制结构：101：3306> 103:3306 > 104:3306 常见主从复制报
全局事务标识符（Global Transaction Identifier,GTID）是MySQL5.6版本开始在主从复制方面推出的重要特性，它是一个已提交事务的编号，并且是全局唯一编号，不仅是在主库上，在给定的复制设置中的所有数据库上，它都是唯一的。
作者个人研发的在高并发场景下，提供的简单、稳定、可扩展的延迟消息队列框架，具有精准的定时任务和延迟队列处理功能。自开源半年多以来，已成功为十几家中小型企业提供了精准定时调度方案，经受住了生产环境的考验。为使更多童鞋受益，现给出开源框架地址：
简单说，复制就是将来自一个MySQL数据库服务器（主库）的数据复制到一个或多个MySQL数据库服务器（从库）。传统的MySQL复制提供了一种简单的Primary-Secondary复制方法，默认情况下，复制是单向异步的。MySQL支持两种复制方式：基于行的复制和基于语句的复制。这两种方式都是通过在主库上记录二进制日志（binlog）、在从库重放中继日志（relylog）的方式来实现异步的数据复制。二进制日志或中继日志中的记录被称为事件。所谓异步包含两层含义，一是主库的二进制日志写入与将其发送到从库是异步进行的，二是从库获取与重放日志事件是异步进行的。这意味着，在同一时间点从库上的数据更新可能落后于主库，并且无法保证主从之间的延迟间隔。
最近在一个生产环境中准备采用mha架构替换目前现网的主从架构，之前为两台服务器一主一从，没有使用vip；架构调整后为4台服务器，1主+1备用主+2slave，2台slave用于处理数据库读请求。两台slave 和备用slave都已开启read_only状态。
从PROXYSQL诞生起，发展有了些年头了，目前已经发展到了2.X ，从以前一个人，到现在成立了公司，更加完善和强大了PROXYSQL 已经成为很多人的选择。
如果主从复制之间出现延时，就会影响主从数据的一致性。 此时发生容灾切换，且在新的主库写入了数据，那么从业务角度上，会产生意想不到的严重后果。 复制延时问题，在只读从库的场景下，若从库产生复制延时，也可能会对业务造成一定影响，比如在业务上表现为读写不一致——新增/修改数据查不到等现象。 由此可见，主从复制的延时问题在数据库运营中需要特别关注。一般来说，DBA在库上执行SHOW SLAVE STATUS，并且观察 Seconds_Behind_Master的值，就能够了解当前某个数据库和它的主库之间的数据复制延时。
mysql 8.0.34和8.1发布了，好像有很大变化的样子，但是又没有，所以研究了一下Release Notes ,其中有一条非常有意思，
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
