进入/mydata/mysql-master/conf目录下新建my.cnf(上面启动容器实例指定的路径)
MySQL主从同步集群在生成环境使用过程中，如果主从服务器之间网络通信条件差或者数据库数据量非常大，容易导致MySQL主从同步延迟。
由于mysql主从复制是基于binlog的一种异步复制 通过网络传送binlog文件，理所当然网络延迟是主从不同步的绝大多数的原因，特别是跨机房的数据同步出现这种几率非常的大，所以做读写分离，注意从业务层进行前期设计。
命令解读： docker run ：创建并运行一个容器 –name : 给容器起一个名字，比如叫做abc -p ：将宿主机端口与容器端口映射，冒号左侧是宿主机端口，右侧是容器端口 -d：后台运行容器 -e：环境变量，如密码什么的 -v：挂载一个数据卷到某个容器内目录，上面分别配置了日志、数据、配置的数据卷
Q：为啥要引入主从同步机制？ A：防止业务数据库突然宕掉，不能快速的恢复业务正常运行，有利于数据库架构的健壮性，提升访问速度，方便运维保证的数据物理安全(容灾备份)；
Hi,各位热爱技术的小伙伴您们好，好久没有写点东西了，今天写点关于mysql主从同步配置的操作日志同大家一起分享。最近自己在全新搭建一个mysql主从同步读写分离数据库简单集群，我讲实际操作步骤整理分享处理，希望对在学习路上的你有所以帮助，当然如果是你是老鸟，写的不好的地方，多多包涵。废话不多说，言归正传，直入主题。
数据库读写分离对于大型系统或者访问量很高的互联网应用来说，是必不可少的一个重要功能。
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来进行位置点的主从复制。
在MySQL数据库中，在进行数据迁移和从库只读状态设置时，都会涉及到只读状态和Master-Slave主从关系设置, 以下针对real_only只读属性做些笔记记录:
主从复制是指将主数据库的DDL和DML操作通过二进制日志传到从数据库上，然后在从数据库上对这些日志进行重新执行，从而使从数据库和主数据库的数据保持一致。
大家好，咱们前面通过十篇的文章介绍了docker的基础篇，从本篇开始，咱们的《docker学习系列》将要进入到高级篇阶段(基础篇大家可以查看之前发布的文章)。
大多数人都很清楚，在高并发的时候，如果所有的数据库操作都只通过一台数据库来操作，那数据库很大程度可能出现宕机，而宕机就有可能导致数据丢失，造成不良后果。所以在并发量高的情况下一般会使用主从同步来实现读写分离。本篇文章主要就是围绕主从同步实现读写分离这个主题去讲解。我们其实在Redis专题中也有提到过主从同步的概念，现在我们可以先看下主从同步和读写分离的具体概念。
这里需要说的是如果你的IO线程状态为connecting或no可能证明你的防火墙有问题 查看一下防火墙规则，放行端口要不就把防火墙关闭 systemctl stop firewalld 关闭防火墙之后 docker restart mysql 当我要重启数据库的时候会报错iptables等一些报错 不要慌。。。不是啥大问题 重启一下docker systemctl restart docker.service 再次重启的时候就不会报错了
新建主服务器容器实例3307 docker run -p 3307:3306 --name mysql-master \ -v /mydata/mysql-master/log:/var/log/mysql \ -v /mydata/mysql-master/data:/var/lib/mysql \ -v /mydata/mysql-master/conf:/etc/mysql \ -e MYSQL_ROOT_PASSWORD=root \ -d mysql:5.7 进入/mydat
最近在梳理数据库集群的相关操作，现在花点时间整理一下关于mysql数据库集群的操作总结，恰好你又在看这一块，供一份参考。本次系列终结大概包括以下内容：多数据库安装、mycat部署安装、数据库之读写分离主从复制、数据库之双主多重、数据库分库分表。每一个点，有可能会对应一篇或者多篇文章，由于还要继续上班工作，所以本系列分享预计持续时间需要10天左右，有兴趣的您可以持续关注。我是一个菜鸟，如果写的不好的地方，望多多指点和包涵。
修改mysql配置文件，不同的系统my.cnf路径不同（CentOS中位于/etc/my.cnf）
（1）主从服务器操作系统版本和位数必须一致； （2）主节点（Master）和从节点（Slave）数据库版本必须一致； （3）主节点（Master）和从节点（Slave）数据库中的数据必须一致； （4）主节点（Master）需要开启二进制日志； （5）主节点（Master）和从节点（Slave）的 server-id 在局域网内必须唯一。
环境 操作系统：CentOS-6.6-x86_64-bin-DVD1.iso MySQL版本：mysql-5.6.26.tar.gz 主节点IP：192.168.1.205 主机名：edu-mysql-01 从节点IP：192.168.1.206 主机名：edu-mysql-02 主机配置：4核CPU、4G内存 依赖课程 《高可用架构篇--第13节--MySQL源码编译安装（CentOS-6.6+MySQL-5.6）》 MySQL主从复制官方文档 http://dev.mysql.com/doc/refma
所以能看到主从同步的内容就是二进制日志（Binlog），它虽然叫二进制日志，实际上存储的是一个又一个事件（Event），这些事件分别对应着数据库的更新操作，比如 INSERT、UPDATE、DELETE 等。另外我们还需要注意的是，不是所有版本的 MySQL 都默认开启服务器的二进制日志，在进行主从同步的时候，我们需要先检查服务器是否已经开启了二进制日志。
上图展示的是 MySQL 的主从切换流程。在 State-1 中，客户端的读写都直接访问节点 A，而节点 B 是 A 的备库，只是将 A 的更新都同步过来，到本地执行。这样可以保持节点 B 和 A 的数据是相同的。当需要切换的时候，就切成状态 2。这时候客户端读写访问的都是节点 B，而节点 A 是 B 的从库。
之前部署了Mysql主从复制环境（Mysql主从同步(1)-主从/主主环境部署梳理），在mysql同步过程中会出现很多问题，导致数据同步异常。 以下梳理了几种主从同步中可能存在的问题: 1）slave运行过慢不能与master同步，也就是MySQL数据库主从同步延迟 MySQL数据库slave服务器延迟的现象是非常普遍的，MySQL复制允许从机进行SELECT操作，但是在实际线上环境下，由于从机延迟的关系，很难将读取操作转向到从机。这就导致了有了以下一些潜规则：“实时性要求不高的读取操作可以放到slave服
这里我们所讨论的连接池是MyCat的后端连接池， 也就是MyCat后端与各个数据库节点之间的连接架构。
关于MySQL数据库的主从复制，网上相关文章多数是基于Linux环境，笔者曾有 实施过Windows环境下MySQL数据库的主从复制。以下文章为笔者实施过程的原始记录，给需要的朋友参考，原创不易，你的点赞是我写作的动力，十分感谢！
准备服务器Server1和Server2，如果在同一个服务器的话则安装mysql时需要改变其端口。
docker run-p3339:3306--name mymysql-e MYSQL_ROOT_PASSWORD=123456-d mysql:5.7
“高可用”是互联网一个永恒的话题，先避开MySQL不谈，为了保证各种服务的高可用有几种常用的解决方案。
在实际使用MySQL的时候我们有时要增加一些新的库进行主从同步，所以可以通过修改my.cnf文件以及在主库上添加用户连接权限就可以实现主从同步，而在做主从同步的时候碰到几个问题这里就和大家说一下，至于如何构建主从同步这里就不再多说了，相信在网上能找到一大堆，这里就稍稍提几个关键点,在从库下的my.cnf添加如下几行：
上文《MySQL数据被误删怎么办？》介绍了MySQL在故障或者误删数据后，可以通过备份+binlog的方式进行数据恢复。但是，当备份文件和binlog都丢失了呢？所以单节点是不可靠的，为了避免单节点故障带来的数据丢失以及MySQL服务的可用性，生产环境通常都是采用高可用或者集群模式。而在这背后则离不开主从复制技术，所以本文对主从复制的原理和操作展开介绍，从而全面了解这一技术。
中文无法插入，详见docker mysql设置编码，修改编码后，一定要重新建库建表测试。
docker run -p 3339:3306 --name mymysql -e MYSQL_ROOT_PASSWORD=123456 -d mysql:5.7
MySQL主从复制(Master-Slave)也叫AB复制，Mysql作为目前世界上使用最广泛的免费数据库，相信所有从事系统运维的工程师都一定接触过。但在实际的生产环境中，由单台Mysql作为独立的数据库是完全不能满足实际需求的，无论是在安全性，高可用性以及高并发等各个方面。因此，一般来说都是通过主从复制（Master-Slave）的方式来同步数据，再通过读写分离（MySQL-Proxy）来提升数据库的并发负载能力这样的方案来进行部署与实施的。
今天我们来详细了解一下主从同步延迟时读写分离发生写后读不到的问题，依次讲解问题出现的原因，解决策略以及 Sharding-jdbc、MyCat 和 MaxScale 等开源数据库中间件具体的实现方案。
之前部署了mysql主从同步环境（Mysql主从同步(1)-主从/主主环境部署梳理），针对主从同步过程中slave延迟状态的监控梳理如下： 在mysql日常维护工作中，对于主从复制的监控主要体现在： 1）检查数据是否一致；主从数据不同步时，参考下面两篇文档记录进行数据修复： mysql主从同步(3)-percona-toolkit工具（数据一致性监测、延迟监控）使用梳理 利用mk-table-checksum监测Mysql主从数据一致性操作记录 2）监控主从同步延迟，同步延迟的检查工作主要从下面两方面着手：
在MySQL中，主从架构应该是最基础、最常用的一种架构了。后续的读写分离、多活高可用架构等大多都依赖于主从复制。主从复制也是我们学习MySQL过程中必不可少的一部分，关于主从复制的文章有很多，笔者也来凑凑热闹，写写这方面的内容吧，同时分享下自己的经验和方法。
如果在开启主从的过程中显示权限不足，按照上面步骤添加 REPLICATION_SLAVE_ADMIN 权限，然后刷新即可。报错信息如下：
很久之前就做过mysql的部分应用架构，包括主从复制和集群等，一直没有形成博客记录下来，虽然网上也有很多的相关资料，但是出于加深记忆，还是把自己的操作步骤和截图一步步记录下来，回头忘了也可以回顾，当然，也希望有小伙伴能得到帮助。
本人是测试环境，准备了两台安装好mysql的服务器（masterA和masterB），可以保证没数据写入，否则需要先将两台服务器上的数据一致，然后再进行主从配置，步骤是：先masterA锁表-->masterA备份数据-->masterA解锁表-->将masterA数据导入masterB-->设置主从。
原理：主从复制是指一台服务器充当主数据库服务器，另一台或多台服务器充当从数据库服务器，主服务器中的数据自动复制到从服务器之中。对于多级复制，数据库服务器即可充当主机，也可充当从机。MySQL主从复制的基础是主服务器对数据库修改记录二进制日志，从服务器通过主服务器的二进制日志自动执行更新。1、新建主服务器示例3307docker run -p 3307:3306 --name mysql-master \-v /mydata/mysql-master/log:/var/log/mysql \-v /mydat
主从复制是指一台服务器充当主数据库服务器，另一台或多台服务器充当从数据库服务器，主服务器中的数据自动复制到从服务器之中。对于多级复制，数据库服务器即可充当主机，也可充当从机。MySQL主从复制的基础是主服务器对数据库修改记录二进制日志，从服务器通过主服务器的二进制日志自动执行更新。
我们要使用docker搭建一个mysql的主从复制，那么就相当于要创建两个容器，一个是主的，一个是从的
MySQL 是最受欢迎的关系型数据库管理系统之一，被广泛应用于各种业务系统。主从复制是MySQL 的重要能力，用于实现数据冗余、提高可用性和性能。了解MySQL主从复制，可以更好地管理和优化数据库，为业务系统提供更强大的支持。
然后set global sql_slave_skip_counter = 1;跳过一步错误
上篇文章我们大致介绍了什么是MySQL主从复制，主从复制的几种集群架构图大概都有哪几种，今天我们就来讲讲如何实现MySQL集群的搭建。主从复制有两种方式可以实现，binlog和GTID，这期我们先通过binlog方式来实现，下篇我们来讲binlog的原理，和注意事项。
前两天 MTSC 2018 在北京国际会议中心圆满召开，并取得非常好的反响，虽然临时有事，没去成，但还是非常赞许为此会议付出的朋友和小伙伴们~
主从复制的根本原理是从 master 服务器上面的数据，通过一定的方式同步到 slave 服务器上面。基本过程如下图：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
