mysql的组复制

                                                     mysql的组复制

先说说数据库复制的各种形式

异步复制模式下,Master上执行事务产生 binlog,slave 通过连接 master 抓取 binlog 的内容接收到本地的
relaylog 上,然后 apply 对应的事务,产生 slave 服务器上自身的 binlog(由--log-slave-update
参数决定)。流程图如下:


其次是半同步复制,流程图如下


异步复制模式下,如果 slave 全部宕机,则在 master 上的事务无法同步到 slave 上,存在一定的数据安全风险。


同步复制解决了数据安全风险的问题,在半同步环境下要求至少有一台 slave 接收到 master 的binlog并成功写入到本地的
relaylog, master
上的事务才可以成功提交,这样对主库的事务提交速度会产生一定影响,半同步在数据安全和数据库性能两者之间做了一个中和。

在实际使用过程中,可以通过配置参数(rpl_semi_sync_master_timeout 单位是毫秒,默认为10000,即10s)设定若 slave 在多长时间没有ack返回,同步模式由半同步自动修改为异步同步模式。

组复制分单主模式和多主模式,mysql 的复制技术仅解决了数据同步的问题,如果 master 宕机,意味着数据库管理员需要介入,应用系统可能需要修改数据库连接地址或者重启才能实现。


组复制的特点:

● 高一致性

基于原生复制及 paxos 协议的组复制技术,并以插件的方式提供,提供一致数据安全保证;

● 高容错性

只要不是大多数节点坏掉就可以继续工作,有自动检测机制,当不同节点产生资源争用冲突时,不会出现错误,按照先到者优先原则进行处理,并且内置了自动化脑裂防护机制;

● 高扩展性

节点的新增和移除都是自动的,新节点加入后,会自动从其他节点上同步状态,直到新节点和其他节点保持一致,如果某节点被移除了,其他节点自动更新组信息,自动维护新的组信息;

● 高灵活性

有单主模式和多主模式,单主模式下,会自动选主,所有更新操作都在主上进行;

多主模式下,所有 server 都可以同时处理更新操作。


目前组复制最多支持一个组中有 9 个 server

做组复制时,注意做好解析/etc/hosts,关闭密码插件,在 /etc/my.conf 中写入,

validate_password=OFF
或是在vim /etc/init.d/mysqld 进行注释[object Object]

实验:

server1    192.168.122.11

server2    192.168.122.12

server3    192.168.122.13

一、配置文件

/etc/my.cnf  

server2,3的配置文件区别仅在于 server-id 与 local_address

复制框架

设置将 server 配置为使用唯一标识号 1,以启用全局事务标识符,并将复制元数据存储在系统表(而不是文件)中。 此外,它设置 server 打开二进制日志记录,使用基于行的格式并禁用二进制日志事件校验和。

组复制设置

第 1 行指示 server 必须为每个事务收集写集合,并使用 XXHASH64 哈希算法将其编码为散列。

第 2 行告知插件,正在加入或创建的组要命名为“aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa”。

第 3 行指示插件在 server 启动时不自动启动组复制。

第 4 行告诉插件使用 本地主机或IP 地址 127.0.0.1 ,端口 24091 用于接受来自组中其他成员的传入连接。

第 5 行告诉插件,当下面这些 server 需要加入组时,应该连接到这些主机和端口上访问他们,这些就是种子成员。

第 6 行指示插件是否自动引导组。此选项在任何时候只能在一个 server 实例上使用,通常是首次引导组时(或在整个组被崩溃然后恢复的情况下)。 如果您多次引导组,例如,当多个 server 实例设置了此选项,则它们可能会人为地造成脑裂的情况,其中存在两个具有相同名称的不同组。 在第一个server 实例加入组后禁用此选项。

二、数据库配置

1.用户凭据

分布式恢复过程依赖于 group_replication_recovery 复制通道,该复制通道用于在组成员之间传输事务。 因此,需要设置具有正确权限的复制用户,以便组复制可以直接建立成员到成员的恢复复制通道。

mysql> SET SQL_LOG_BIN=0;    关闭二进制日志

mysql> grant replication slave on *.* to [email protected]'%' identified by 'LH=liuhuan123';    创建 rpl_user 用户并且授权使之可以进行复制功能

mysql> flush privileges; 

mysql> SET SQL_LOG_BIN=1;    开启二进制日志

mysql> change master to master_user='rpl_user',master_password='LH=liuhuan123' for channel 'group_replication_recovery';    下次需要从其他成员恢复其状态时,使用 group_replication_recovery 复制通道的给定凭据.。

2.启动组复制

mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';    安装插件

mysql> SET GLOBAL group_replication_bootstrap_group=ON;    server1引导组,启动组复制程序,只用在组复制成员中执行一次即可。不可将此参数写在配置文件中,因为在下一次启动组复制时,会有两个不同的组有相同的名称。

mysql> START GROUP_REPLICATION;    启动 server1的组复制

mysql> SET GLOBAL group_replication_bootstrap_group=OFF;    将引导组复制的程序关闭,其余成员直接加入该组即可。

mysql> SELECT * FROM performance_schema.replication_group_members;  查看

三、向组中添加实例

server2端

mysql> SET SQL_LOG_BIN=0;
mysql> grant replication slave on *.* to [email protected]'%' identified by 'LH=liuhuan123';
mysql> SET SQL_LOG_BIN=1;
mysql> CHANGE MASTER TO MASTER_USER='rpl_user',MASTER_PASSWORD='LH=liuhuan123' for CHANNEL 'group_replication_recovery';

mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';    安装插件

mysql> start group_replication;    将 server2 添加到组

查日志得:

上网查找(网站 bing.com)

server3同理,查看mysql> SELECT * FROM performance_schema.replication_group_members;


四、高可用验证

1、验证数据写入

server1端,写入数据


server2,3端查看

2、模拟宕机一个节点验证

关闭server2

在server1写入数据

启动server2

再次查看组成员,发现server2已重新加入组

查看数据,发现数据已同步


原文地址:http://blog.51cto.com/13362895/2129109

时间: 2024-10-09 17:44:04

mysql的组复制的相关文章

MGR——Mysql的组复制之多主模式

组复制可以在两种模式下运行. 1.在单主模式下,组复制具有自动选主功能,每次只有一个 server成员接受更新.2.在多主模式下,所有的 server 成员都可以同时接受更新. 组复制与异步主从复制区别. 1.传统mysql主从复制,是在主节点执行和提交事务,然后把他们异步的发送到从节点,行复制的重新执行主节点的SQL语句,这是一个 shared-nothing 的系统,默认情况下所有 server 成员都有一个完整的数据副本. 2.半同步复制,它在协议中添加了一个同步步骤. 这意味着主节点在提

[MGR——Mysql的组复制之多主模式 ] 详细搭建部署过程

组复制可以在两种模式下运行. 1.在单主模式下,组复制具有自动选主功能,每次只有一个 server成员接受更新.2.在多主模式下,所有的 server 成员都可以同时接受更新. 组复制与异步主从复制区别. 1.传统mysql主从复制,是在主节点执行和提交事务,然后把他们异步的发送到从节点,行复制的重新执行主节点的SQL语句,这是一个 shared-nothing 的系统,默认情况下所有 server 成员都有一个完整的数据副本. 2.半同步复制,它在协议中添加了一个同步步骤. 这意味着主节点在提

[MGR——Mysql的组复制之单主模式 ]详细搭建部署过程

1,关于MySQL Group Replication 基于组的复制(Group-basedReplication)是一种被使用在容错系统中的技术.Replication-group(复制组)是由能够相互通信的多个服务器(节点)组成的. 在通信层,Groupreplication实现了一系列的机制:比如原子消息(atomicmessage delivery)和全序化消息(totalorderingof messages). 这些原子化,抽象化的机制,为实现更先进的数据库复制方案提供了强有力的支持

实践 Mysql Group Replication 组复制

实践过程: 在一台服务器上安装3个MySQL(s1,s2,s3) 配置s1,启动 Group Replication 配置s2,添加到组中 配置s3,添加到组中 测试 内容比较长,可能不方便实际操作,我也做了一个PDF版本,您可以下载查看,发送消息 'gr' 会自动回复下载地址 详细配置过程 (1)下载 mysql-5.7.17 https://cdn.mysql.com//Downloads/MySQL-5.7/mysql-5.7.17-linux-glibc2.5-x86_64.tar.gz

Mysql Group Replication 简介及单主模式组复制配置【转】

一 Mysql Group Replication简介 Mysql Group Replication(MGR)是一个全新的高可用和高扩张的MySQL集群服务. 高一致性,基于原生复制及paxos协议的组复制技术,以插件方式提供一致数据安全保证: 高容错性,大多数服务正常就可继续工作,自动不同节点检测资源征用冲突,按顺序优先处理,内置自动防脑裂机制: 高扩展性,自动添加移除节点,并更新组信息: 高灵活性,单主模式和多主模式.单主模式自动选主,所有更新操作在主进行:多主模式,所有server同时更

MySQL组复制(4):配置多主模型的组复制

在这一篇,我演示的是如何配置MySQL组复制的多主模型(multi-primary).在配置上,多主模型的组复制和单主模型基本没区别. 本文仅为搭建和维护多主模型组复制抛块小砖,若对其间涉及的术语和理论有所疑惑,可参看: 单主模型相关内容的大长文:配置单主模型的组复制. 组复制的理论:MySQL组复制官方手册翻译. 使用组复制技术,必须要了解它的要求和局限性.见:组复制的要求和局限性. 1.组复制:单主和多主模型 MySQL组复制支持单主模型和多主模型,它们都能保证MySQL数据库的高可用. 单

MySQL组复制(1):组复制技术简介

1.MySQL高可用的背景 数据库的主从复制是一个很实用的功能,但如何保证它的高可用却是一件难事.实现MySQL主从复制高可用的工具,常见的有: (1).MMM:淘汰了,在一致性和高并发稳定性等方面有些问题. (2).MHA:有些人还在用,但也有些问题,也是趋于淘汰的MySQL主从高可用方案. (3).Galera:引领时代的主从复制高可用技术. (4).MariaDB Galera Cluster:MariaDB对Galera的实现. (5).PXC:Percona XtraDB Cluste

MySQL中间件之ProxySQL(15):ProxySQL代理MySQL组复制

返回ProxySQL系列文章:http://www.cnblogs.com/f-ck-need-u/p/7586194.html 1.ProxySQL+组复制前言 在以前的ProxySQL版本中,要支持MySQL组复制(MGR,MySQL Group Replication)需要借助第三方脚本对组复制做健康检查并自动调整配置,但是从ProxySQL v1.4.0开始,已原生支持MySQL组复制的代理,在main库中也已提供mysql_group_replication_hostgroups表来控

MySQL 主主复制 + LVS + Keepalived 实现 MySQL 高可用性

MySQL复制能够保证数据的冗余的同时可以做读写分离来分担系统压力,如果是主主复制还可以很好的避免主节点的单点故障.但是MySQL主主复制存在一些问题无法满足我们的实际需要:未提供统一访问入口来实现负载均衡,如果其中master宕掉的话需要手动切换到另外一个master,而不能自动进行切换. 这篇文章下面要介绍如何通过LVS+Keepalived的方式来是实现MySQL的高可用性,同时解决以上问题. Keepalived和LVS介绍 Keepalived是一个基于VRRP(虚拟路由冗余协议)可用