MariaDB 10 Slave Crash-Safe需转为GTID复制模式

之前写了一篇《MySQL5.6 crash-safe replication》 ,但在Mariadb10.0.X和10.1.X上不支持relay_log_info_repository = TABLE参数,官网建议用GTID复制模式代替传统复制模式,传统复制模式是不支持Slave Crash-Safe的。

在mysql库下,会有一张gtid_slave_pos表(在安装初始化时,就已经是innodb引擎)

START TRANSACTION;
-- Statement 1
-- ...
-- Statement N
-- Update replication info
COMMIT;

这样sql线程执行完事务后,立即会更新gtid_slave_pos表,如果在更新过程中宕机,事务会回滚,gtid_slave_pos表并不会记录同步的点,下次重新同步复制时,从之前的POS点再次执行。

MariaDB 10默认是传统复制,如果转为GTID复制很简单,并不需要像MySQL5.6那样,要在Slave从库上设置log_slave_updates = 1(增加从库的IO压力),并重启数据库生效那么麻烦。MariaDB支持热切换GTID,你可以先以传统复制搭建主从,然后再热切GTID复制模式,如下图:

通过几个简单的步骤,Slave从库就支持了Crash-Safe。

注:MHA0.56(最新版),还不支持MariaDB10的GTID复制模式,在故障切换时,还会以传统复制搭建主从,所以需要每次手工热切换下GTID模式。

参考官网:

时间: 2025-01-02 17:28:32

MariaDB 10 Slave Crash-Safe需转为GTID复制模式的相关文章

MySQL5.7 开启GTID复制模式终于不用开启log_slave_updates参数了

MySQL5.6的GTID复制模式,必须开启log_slave_updates参数,否则启动就报错,因为需要在binlog找到同步复制的信息(UUID:事务号),如果在密集型写的环境,比如双十一大促在线支付,这无疑增加了从库不必要的磁盘IO开销. (注:开启log_slave_updates参数,是把relay-log里的日志内容再记录到slave本地的binlog里.) 但在MySQL5.7里,官方终于做了调整,用一张gtid_executed系统表记录同步复制的信息(UUID:事务号),这样

mysql 5.6 的新特性:GTID 复制

mysql 5.6 的新特性: MySQL 5.6 包含了一个复制的新功能,enabling DevOps teams to reliably scale-out their MySQL infrastructure across commodity hardware, rel="nofollow">Global Transaction Identifiers (GTIDs)功能, 为了解决以下问题: -能够无缝的故障恢复和master与slave的切换 -能把slave指向新的

深入MySQL复制(二):基于GTID复制

相比传统的MySQL复制,gtid复制无论是配置还是维护都要轻松的多.本文对gtid复制稍作介绍. MySQL基于GTID复制官方手册:https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html 1.gtid基本概念 传统的基于binlog position复制的方式有个严重的缺点:如果slave连接master时指定的binlog文件错误或者position错误,会造成遗漏或者重复,很多时候前后数据是有依赖性的,这样就会出错而导

MariaDB 10 基于OpenSSL的主从复制

需求架构 准备工作 主从服务器时间同步 # 主从服务器同时配置crontab任务,与NTP服务器同步时间即可 */5 * * * * ntpdate 172.16.0.1 &>/dev/null 部署配置 主库配置 vi /etc/my.cnf server-id = 1 # 在复制架构中,需保持全局唯一 log-bin = mysql-bin # 默认在数据目录下 sync_binlog = 1 # 设置mariadb每次在提交事务前会将二进制日志同步到磁盘,保证服务器崩溃时不会丢失事件

InnoSQL HA Suite的实现原理与配置说明 InnoSQL的VSR功能Virtual Sync Replication MySQL 5.5版本引入了半同步复制(semi-sync replicaiton)的功能 MySQL 5.6支持了crash safe功能

InnoSQL HA Suite的实现原理与配置说明  InnoSQL的VSR功能Virtual Sync Replication MySQL 5.5版本引入了半同步复制(semi-sync replicaiton)的功能 MySQL 5.6支持了crash safe功能 http://www.innomysql.net/article/7403.html Virtual Sync Replication 搭建一个MySQL数据库的复制(replication)环境是相当简单的,这点是MySQL

MariaDB的GTID复制和多源复制

什么是GTID? GTID就是全局事务ID(global transaction identifier ),最初由google实现,官方MySQL在5.6才加入该功能.GTID实际上是由UUID+TID组成的.其中UUID是一个MySQL实例的唯一标识.TID代表了该实例上已经提交的事务数量,并且随着事务提交单调递增. 什么是多源复制? 多源复制意味着一个服务器能从多个从服务器上复制.这是MariaDB 10.0的一个新特性. 实验系统:CentOS 6.6_x86_64 实验前提:防火墙和se

MariaDB GTID 复制同步

MariaDB GTID 复制同步 GTID:Global Transaction ID,全局事务ID,在整个主从复制架构中任何两个事物ID是不能相同的.全局事务ID是Mster服务器生成一个128位的UUID+事物的ID号组成的,UUID标示主服务器的身份,此UUID在整个主从复制架构中是绝对唯一,而且即使更换主服务器后UUID也不会改变而是继承当前主服务器的UUID身份. 一.环境确认 master  IP : 10.6.0.96 slave   IP :  10.6.0.138 配置本地h

关于MariaDB.10.5.1 主从复制介绍

提示:本博文演示环境是基于centos7.2 x86_64位,最小化安装系统,MariaDB.10.5.1二进制安装来进行的 一.简单介绍下slave库的并行复制模式 slave_parallel_mode的 slave并行复制的5种模式:官方给的5种模式 Description: Controls what transactions are applied in parallel when using parallel replication. optimistic: tries to app

mariadb 10 多源复制(Multi-source replication) 业务使用场景分析,及使用方法

mariadb 10 多源复制(Multi-source replication) 业务使用场景分析,及使用方法 官方mysql一个slave只能对应一个master,mariadb 10开始支持多源复制,一个slave可以有多个master,分别从各自的master复制不同的DB. 这个特性可以用在OLAP环境中,传统电商DB都是拆了再拆,分库分表,sharding,而OLAP环境或者大数据平台环境,通常需要各种数据的聚合,多个平台多个DB数据的复合查询,而这些数据分散在各个库中,怎么办了,当