mysql主主同步

文章目录 MySQL 主备原理 binlog 的 3 种格式 statement row mixed 循环复制问题 我们知道MySQL中的binlog 可以用来归档，同时也可以用来做主从同步，今天来详细介绍一下。 MySQL 主备原理 从上面流程可以看出，A 节点是主库，B 节点是从库。通常情况下从库我们会设置为 readonly ，这样可以防止因业务代码中的切换 BUG 造成 在从库写数据；同时我们也可以通过 readonly 的状态来判断，节点的主从状态。 下面我们看一下，一个 update 语句在 A、B 节点上面的数据流转。 上图包含了 binlog 和 redo log 的写入机制，备库 B 和 A 之间维持了一个长连接。主库 A 里面有一个线程，专门服务于备库 B 。一个事务的同步的完整过成如下： 在备库 B 上面通过 change master 命令，设置主库 A 的IP、端口、用户名、密码，以及需要同步主库 binlog 的位置； 在备库 B 上执行 start slave 命令，这个时候备库会启动 2 个线程，就是图中的 io_thread 和 sql_thread。其中 io_thread 负责和主库建立连接； 主库校验完成之后，开始从指定 binlog 位置读取，并传送给备库 B； 备库 B 拿到 binlog 后写到本地（relay log）； sql

一、环境介绍 centos7，mysql5.6 master： 10.0.0.42 slave： 10.0.0.43,10.0.0.44 二、配置 vim /etc/my.cnf master： 10.0.0.42 slave： 10.0.0.43 slave： 10.0.0.44 注：此处允许所有ip地址可以远程登录此mysql，出于安全考虑，可以配置防火墙规则进行mysql远程登录的ip的限制。 在master上授权一个远程登录用户并刷新权限，查看master状态 slave机上分别执行 change master to master_host = '10.0.0.42' , master_user = 'tom' , master_password = '123' , master_log_file = 'mysql-log.000003' , master_log_pos = 442 ; 然后开启两台从机 查看slave的状态 当从库的 IO线程和SQL线程的状态都是yes时，说明主从模式配置成功 可以创建一个数据库测试是否可以同步成功 来源： CSDN 作者： 一纸情书ベ 链接： https://blog.csdn.net/weixin_45762569/article/details/103741099

当我们配置好MySQL主主同步时，是可以实现主主同步，但是重启机器后就发现无法同步了 二、两个关键进程： mysql replication 中slave机器上有两个关键的进程，死一个都不行，一个是slave_sql_running，一个是Slave_IO_Running， 一个负责与主机的io通信，一个负责自己的slave mysql进程。 问题一 ： Slave_io_running：No 解决： 你去主的机子上 192.168.194.154 mysql> show master status \G; 这是在 192.168.194.155 mysql > stop slave mysql > CHANGE MASTER TO MASTER_LOG_FILE = 'mysql-bin.000002' , MASTER_LOG_POS = 0 ; mysql > start slave ; 问题二、Slave_SQL_Running：No mysql> stop slave; mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; mysql> start slave; mysql> show slave status\G 来源： CSDN 作者： dajiahao 链接： https://blog.csdn.net

1、简介 MySQL作为世界上使用最为广泛的数据库之一，免费是其原因之一。但不可忽略的是它本身的功能的确很强大。随着技术的发展，在实际的生产环境中，由单台MySQL数据库服务器不能满足实际的需求。此时数据库集群就很好的解决了这个问题了。采用MySQL分布式集群，能够搭建一个高并发、负载均衡的集群服务器（这篇博客暂时不涉及）。在此之前我们必须要保证每台MySQL服务器里的数据同步。数据同步我们可以通过MySQL内部配置就可以轻松完成，主要有主从复制和主主复制。 回到顶部 2、环境说明 两台linux虚拟主机 Linux版本CentOS6.6、MySQL 5.5 ip：192.168.95.11、192.168.95.12 回到顶部 3、主从复制 回到顶部 3.1、MySQL 已经安装好，并且没有任何数据 回到顶部 3.2、配置文件 一般Linux中的MySQL配置文件都在/etc/my.cnf(windows中的配置文件为mysql.ini) log-bin=mysql-bin 开启二进制日志 注意：二进制日志必须开启，因为数据的同步实质上就是其他的MySQL数据库服务器将这个数据变更的二进制日志在本机上再执行一遍。 192.168.95.11 为主数据库服务器 192.168.95.12 为从数据库服务器 回到顶部 3.3、开始构建主从复制 第一步： 在192.168.95

binlog 可以用来归档，也可以用来做主备同步，但它的内容是什么样的呢？为什么备库执行了 binlog 就可以跟主库保持一致了呢？今天就正式地来介绍一下它。 MySQL 主备的基本原理 M-S 结构： 在状态 1 中，客户端的读写都直接访问节点 A，而节点 B 是 A 的备库，只是 将 A 的更新都同步过来 ，到本地执行。这样可以保持节点 B 和 A 的数据是相同的。 当需要切换的时候，就切成状态 2。这时候客户端读写访问的都是节点 B，而节点 A 是 B 的备库。 节点 A 到 B 这条线的内部流程 备库 B 跟主库 A 之间维持了一个 长连接 。主库 A 内部有一个线程，专门用于服务备库 B 的这个长连接。一个 事务日志同步的完整过程 是这样的： 在备库 B 上通过 change master 命令，设置主库 A 的 IP、端口、用户名、密码 ，以及要从哪个位置开始请求 binlog，这个位置包含文件名和日志偏移量。 在备库 B 上执行 start slave 命令，这时候备库会启动 两个线程 ，就是图中的 io_thread 和 sql_thread 。其中 io_thread 负责与主库建立连接 。 主库 A 校验完用户名、密码后，开始按照备库 B 传过来的位置，从本地读取 binlog， 发给 B 。 备库 B 拿到 binlog 后，写到本地文件，称为 中转日志

Galera Cluster特点 1、多主架构：真正的多点读写的集群，在任何时候读写数据，都是最新的 2、同步复制：集群不同节点之间数据同步，没有延迟，在数据库挂掉之后，数据不会丢失 3、并发复制：从节点APPLY数据时，支持并行执行，更好的性能 4、故障切换：在出现数据库故障时，因支持多点写入，切换容易 5、热插拔：在服务期间，如果数据库挂了，只要监控程序发现的够快，不可服务时间就会非常少。在节点故障期间，节点本身对集群的影响非常小 6、自动节点克隆：在新增节点，或者停机维护时，增量数据或者基础数据不需要人工手动备份提供，Galera Cluster会自动拉取在线节点数据，最终集群会变为一致 7、对应用透明：集群的维护，对应用程序是透明的 Galera Cluster工作过程 客户端发送更新指令到mysql服务器，服务器回复OK，但客户端有可能以事务方式执行，并没有发送确认指令（commit）；当客户端发送commit指令确认后，mysql服务器会把数据库的更新复制到同一个集群的其他节点；集群中的所有节点会对数据库的更新进行校验，检查更新完的数据与数据库中的数据是否冲突，如果不冲突，服务器端会回复OK；如果更新的数据与集群中的任意一个节点数据发生冲突，则都会回复error 实现Galera Cluster集群 至少需要三台机器;并且Galera Cluster也是一个数据库服务

准备 1 1. 双主 master1 192.168.199.49 2 master2 192.168.199.50 3 VIP 192.168.199.52 //虚拟IP 4 2.环境 master:nginx + php + mysql + keepalived 5 VIP:只要和master在一个局域网内即可。 6 3. 服务器之间网络通畅，可以互相ping通。 7 4. 2个服务器的mysql版本要一致。数据库密码一致 8 5. 防火墙增加允许组播和允许VRRP（虚拟路由器冗余协）通信，这样主服务器在故障恢复后才能抢回资源 9 -A INPUT -s 182.148.15.0/24 -d 224.0.0.18 -j ACCEPT 10 -A INPUT -s 182.148.15.0/24 -p vrrp -j ACCEPT 11 重启生效：service iptables reload 配置服务器 1 服务器1： 2 3 在my.cnf文件的[mysqld]配置区域添加下面内容： 4 log-bin=mysql-bin #记录二进制文件 5 binlog_format=mixed #mysql默认采用的二进制格式 6 server-id = 2 #服务号，必须是唯一的，一般取IP的后8位 7 expire_logs_days = 10 #binlog过期清理时间 8 9

架构展示 操作系统 centos6.5 数据库 mysql5.7 master1 10.0.254.148 master2 10.0.254.147 VIP 10.0.254.88 （keepalived） 最好在自己的内网VIP 一、创建操作系统 centos6.5 关闭selinux 关闭防火墙 iptables 二、每台机器都安装数据库 编译安装 不作介绍需要配置/etc/my.cnf 文件 master1的my.cnf 文件配置 启动mysql /etc/init.d/mysqld start master2的my.cnf文件配置 启动mysql /etc/init.d/mysqld start 完成以上操作之后，需要对两台机器做权限分配以及主主配置 需要同时进行配置两台机器 grant replication slave,replication client on *.* to guoshang@'%' identified by '1qaz!QAZ1qaz'; flush privileges; flush tables with read lock; 锁表 show master status; 查看master情况 +------------------+----------+--------------+------------------+-----------

一、 Mysql1配置 vi /etc/my.cnf.d/server.cnf [mysqld] #作为主从复制的唯一标识，集群中，不能重复 server-id = 1 #开启二进制日志 log-bin = master-log #开启中继日志 relay-log = slave-log auto_increment_offset = 1 auto_increment_increment = 2 二、MySQL2配置 vi /etc/my.cnf.d/server.cnf [mysqld] #作为主从复制的唯一标识，集群中，不能重复 server-id = 2 #开启二进制日志 log-bin = master-log #开启中继日志 relay-log = slave-log auto_increment_offset = 2 auto_increment_increment = 2 三、重启MySQL服务 systemctl restart mysqld 四、MySQL1为主，MySQL2为从配置 　　在MySQL1 中执行sql>> mysql> create user 'lan'@'192.168.11.%' identified by '666666'; mysql> grant replication slave on *.* to 'lan'@'192.168.11.

一、 MySQL于keepalived简介* * 前言： 在企业中，数据库高可用一直是企业的重中之重，中小企业很多都是使用mysql主从方案，一主多从，读写分离等，但是单主存在单点故障，从库切换成主库需要作改动。因此，如果是双主或者多主，就会增加mysql入口，增加高可用。不过多主需要考虑自增长ID问题，这个需要特别设置配置文件，比如双主，可以使用奇偶，总之，主之间设置自增长ID相互不冲突就能完美解决自增长ID冲突问题。 1.1、 MySQL* * 1.1.1、MySQL主从复制原理 复制分成三步： \1. master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）； \2. slave将master的binary log events拷贝到它的中继日志(relay log)； \3. slave重做中继日志中的事件，将改变反映它自己的数据。 下图描述了这一过程： 1.1.2、MySQL双主构建思路 1.两台mysql都可读写，互为主备，默认只使用一台（masterA）负责数据的写入，另一台（masterB）备用； 2.masterA是masterB的主库，masterB又是masterA的主库，它们互为主从； 3.两台主库之间做高可用,可以采用keepalived等方案（使用VIP对外提供服务）； 4