MySQL数据库高可用HA实现小结

目录
  • MySQL数据库高可用HA实现
    • 1、 数据库高可用分析
    • 2、MySQL主从复制的容灾处理
  • 1. 什么是数据库高可用
    • 1.1. 什么是高可用集群
    • 1.2. 高可用集群的衡量标准
    • 1.3. 实现高可用的三种方式
    • 1.4. MySQL数据的高可用实现
      • 1.4.1. 主从方式(⾮对称)
      • 1.4.2. 配置主从服务步骤
  • Master服务器配置
  • Slave服务器配置
  • 主库授权
  • 初始化数据
  • 创建复制链路
  • 从库的binlog是否写⼊?
  • 问题:只同步其中三个表
  • 1.4.2.1. GTID的⽅式来进⾏主从复制
  • 2. 数据主从复制方式的容灾处理
    • 2.1. MySQL⽀持的复制格式
      • 2.1.1. 基于语句的复制(statement)
      • 2.1.2. 基于行复制(row)
      • 2.1.3. 混合类型的复制(MIXED)
  • 2.1. MySQL主从复制模式

MySQL数据库高可用HA实现

1、 数据库高可用分析

高可用的衡量标准
数据库实现高可用的几种⽅式
MySQL数据库实现高可用

2、MySQL主从复制的容灾处理

MySQL支持的复制方式分析
主从场景切换方式
主从结构如何实现容灾

1. 什么是数据库高可用

1.1. 什么是高可用集群

N+1:N就是集群,1就是高可用,⾼可⽤的核⼼就是冗余,集群是保证服务最低使用标准的

1.2. 高可用集群的衡量标准

一般是通过系统的可靠性和可维护性来衡量的
MTTF:平均无故障时间,这是衡量可靠性的
MTTR:衡量系统的可维护性的
HA=MTTF/(MTTF+MTTR)*100%
SLA:99.999%:表示⼀年故障时间/宕机时间不超过6分钟

1.3. 实现高可用的三种方式

主从方式(⾮对称)
    这种⽅式的组织形式通常都是通过两个节点和⼀个或多个服务器,其中⼀台作为主节点
(active),另⼀台作为备份节点(standy),备份节点应该随时都在检测主节点的健康状况,当
    主节点发⽣故障,服务会⾃动切换到备份节点保障服务正常运⾏
对称⽅式
    两个节点,都运⾏着不同的服务且相互备份,相互检测对⽅的健康,当任意⼀个节点发⽣故障,这
    个节点上的服务就会⾃动切换到另⼀节点
多机方式
    包含多个节点多个服务,每个节点都要备份运⾏不同的服务,出现问题⾃动迁移

1.4. MySQL数据的高可用实现

1.4.1. 主从方式(⾮对称)

资源:两台同版本的MySQL数据库
主从实现的内部运行原理和机制
    First Step:主数据库服务器会把数据的修改记录记录进binlog⽇志,binlog⼀定要打开
    Second Step:从库的I/O进行读取主库的binlog内容后存⼊⾃⼰的Relay Log中继⽇志中,这
    个I/O线程会和主库建⽴⼀个普通的客户端连接,然后主库启动⼀个⼆进制转储线程,I/O线
    程通过转储线程读取binlog更新事件,同步完毕后I/O进⼊sleep,有新的更新会再唤醒
            Relay Log和Binlog的格式是⼀样的,可以⽤mysqlbinlog读取,也可show
            mysql> show relaylog events in 'relay-log.000001';
            ⽬前数据库有两种复制⽅式
                    binlog⽇志点position
                    GTID⽅式也要依赖binlog
    第三步:从服务器的SQL进程会从Relay Log中读取事件并在从库中重放
            从服务器执⾏重放操作时是可以在配置⾥声明是否写⼊服务器的binlog⽇志中

1.4.2. 配置主从服务步骤

1.4.2.1. Binlog的⽇志点⽅式配置主从同步

配置主从服务器参数
在Master服务器上创建⽤于复制并授权的数据库账号
备份Master数据库并初始化Slave服务器数据
启动复制链路

Master服务器配置

chown -R mysql:mysql /usr/local/binlog/
#配置⽂件
server_id=163
log_bin=/usr/local/binlog/mysql-bin
12345

Slave服务器配置

server_id=196
log_bin=/usr/local/binlog/mysql-bin
relay_log=/usr/local/relaylog/relay-bin
#当slave宕机后,如果relay log损坏了,导致⼀部分中继⽇志没有处理,则放弃所有未完成的,
重新获取执行,保证完整性
relay_log_recovery=1 #让从库数据只读,super用户,super_read_only=on
read_only=on
#从库的复制链路服务不会随数据库重启而重启,需要手动启动
skip_slave_start=on
#确保数据⼀致性,通过innoDB的崩溃恢复机制来保护哦
master_info_repository=TABLE
relay_log_info_repository=TABLE
#select * from mysql.slave_master_info;
#select * from mysql.slave_relay_log_info;

主库授权

mysql> use msyql;
mysql> grant replication slave on *.* to 'syncuser'@'192.168.0.103'
identified by '123456';
mysql> flush privileges;
set global validate_password_policy=LOW;
set global validate_password_length=6;

初始化数据

mysqldump -uroot -p123456 --master-data=2 --single-transaction --routines -
-triggers --events --databases mydb > mydb.sql

创建复制链路

mysql>
CHANGE MASTER TO
MASTER_HOST='192.168.0.102',
MASTER_PORT=3306,
MASTER_USER='syncuser',
MASTER_PASSWORD='123456',
MASTER_LOG_FILE='mysql-bin.000001',
MASTER_LOG_POS=8122;
mysql> start slave;
mysql> show slave status \G;

从库的binlog是否写⼊?

默认情况下是不写入的:因为写入binlog会消耗I/O,所以性能会下降,如果需要在从库上恢复数
据就到Relay Log里进⾏导出处理
直接在从库上操作更⾏语句则会写入binlog
如果就是需要写入?在从库的my.cnf : log_slave_updates=on #开启同步并写入binlog
开启同步并写入binlog应用于从到从的情况

问题:只同步其中三个表

#Master配置⽂件
#不同步哪些数据库
binlog-ignore-db=mysql
binlog-ignore-db=test
binlog-ignore-db=information_schema
#同步哪些库
binlog-do-db=game
binlog-do-db=mydb

#Slave配置⽂件
#复制哪些数据库
replicate-do-db=mydb
replicate-do-db=game
#不复制哪些数据库
replicate-ignore-db=mysql
replicate-ignore-db=test

--replicate-wild-ignore-table=foo%.bar% 不复制使⽤表名称以开头foo且表名称以开头
的表的更新bar

1.4.2.1. GTID的⽅式来进⾏主从复制

不同点
	主从服务器的参数有不同的地⽅

#在上⾯的基础上,需要给主从服务器都加上
gtid_mode=on
enforce_gtid_consistency=on #开启强制GTID的⼀致性确保事务		

GTID下复制链路的启动
mysql>
CHANGE MASTER TO
MASTER_HOST='192.168.0.102',
MASTER_PORT=3306,
MASTER_USER='syncuser',
MASTER_PASSWORD='123456',
MASTER_AUTO_POSITION=1;

启动GTID后以下数据库操作不可⽤
	create table tableName.... select
	在⼀个事务中创建临时表
	在⼀个transaction中更新innoDB表和myisam表

2. 数据主从复制方式的容灾处理

2.1. MySQL⽀持的复制格式

2.1.1. 基于语句的复制(statement)

优点:记录少,只记录执行语句,易懂
    缺点:insert into table1(create_time) values(now()),这个now就不是当时的时间了

2.1.2. 基于行复制(row)

优点:几乎没有基于行复制⽆法处理的场景
    缺点:数据量太大了

2.1.3. 混合类型的复制(MIXED)

mixed格式默认采用statement,比如⽤到UUID(),ROW_COUNT()

2.1. MySQL主从复制模式

异步复制:MySQL默认就是异步复制,性能最好,但主从复制的数据不⼀致性概率最⼤
同步复制:当客户端发过来⼀个请求后,只有当所有的从库都写到Relay Log中,才回复给前端事
务完成,性能最差,但⼀致性很强
半同步复制:⾄少⼀个从库完成Relay Log写⼊后就返回事务完成给前端

主从上都要安装
mysql> install plugin rpl_semi_sync_master soname='semisync_master.so'
rpl_semi_sync_master_enabled
rpl_semi_sync_master_timeout #单位是毫秒,如果主库等待从库回复超过这个时间就⾃动切换
为异步

到此这篇关于MySQL数据库高可用HA实现的文章就介绍到这了,更多相关MySQL数据库高可用HA内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • MySQL数据库索引以及失效场景详解

    目录 1. MySQL索引概述 1.1 索引的概念 1.2 索引的特点 1.3 索引的分类 1.4 索引的使用场景 2. 索引失效场景 2.1 索引失效9种场景 2.2 索引失效场景总结 3. 索引失效验证 3.1 全值匹配 3.2 最佳左前缀 3.3 索引计算 3.4 索引范围:索引列上不能有范围查询 3.5 索引覆盖:尽量使用覆盖索引 3.6 不等: 使用不等于(!= 或者 <>)的时候 3.7 null:字段的is not null 与is null 3.8 like:like的前后模糊

  • MySQL数据库JDBC编程详解流程

    目录 一.数据库编程的必备条件 二.Java的数据库编程:JDBC 三.JDBC工作原理 四.JDBC开发步骤 五.JDBC操作步骤 六.优化JDBC的部分代码 1.获取数据库连接对象 2.操作命令对象Statement 3.ResultSet对象 4.总结 一.数据库编程的必备条件 编程语言: 如Java.C++.C.Python等 数据库: 如Oracle.MySQL.SQL Server等 数据库驱动包: 不同的数据库,要使用编程语言来操作时,就需要使用该数据库厂商提供的数据库驱动包. 如

  • MYSQL数据库中常用函数介绍

    目录 1 基本函数 2 三角函数 3 进制转换函数 4 字符串函数 5 日期和时间 6 指数和对数 7 流程控制函数 8 加密与解密函数 9 MYSQL信息函数 总结 1 基本函数 2 三角函数 2.1 角度与弧度的换算 3 进制转换函数 4 字符串函数 5 日期和时间 5.1 获取日期和时间 5.2 日期与时间戳的转换 5.3 获取月份.星期.天数 6 指数和对数 7 流程控制函数 8 加密与解密函数 -- 不可逆 SELECT MD5( 'MYSQL' ), SHA( 'MYSQL' ) F

  • MySQL数据库高可用HA实现小结

    目录 MySQL数据库高可用HA实现 1. 数据库高可用分析 2.MySQL主从复制的容灾处理 1. 什么是数据库高可用 1.1. 什么是高可用集群 1.2. 高可用集群的衡量标准 1.3. 实现高可用的三种方式 1.4. MySQL数据的高可用实现 1.4.1. 主从方式(⾮对称) 1.4.2. 配置主从服务步骤 Master服务器配置 Slave服务器配置 主库授权 初始化数据 创建复制链路 从库的binlog是否写⼊? 问题:只同步其中三个表 1.4.2.1. GTID的⽅式来进⾏主从复制

  • Oracle和MySQL的高可用方案对比分析

    关于Oracle和MySQL的高可用方案,其实一直想要总结了,就会分为几个系列来简单说说.通过这样的对比,会对两种数据库架构设计上的细节差异有一个基本的认识.Oracle有一套很成熟的解决方案.用我在OOW上的ppt来看,是MAA的方案,今年是这个方案的16周年了. 而MySQL因为开源的特点,社区里推出了更多的解决方案,个人的见解,InnoDB Cluster会是MySQL以后的高可用方案标配. 而目前来看,MGR固然不错,MySQL Cluster方案也有,PXC,Galera等方案,个人还

  • MySQL之高可用集群部署及故障切换实现

    一.MHA 1.概念 2.MHA 的组成 3.MHA 的特点 二.搭建MySQL+MHA 思路和准备工作 1.MHA架构 数据库安装 一主两从 MHA搭建 2.故障模拟 模拟主库失效 备选主库成为主库 原故障主库恢复重新加入到MHA成为从库 3.准备4台安装MySQL虚拟机 MHA高可用集群相关软件包 MHAmanager IP:192.168.221.30 MySQL1 IP:192.168.221.20 MySQL2 IP:192.168.221.100 MySQL3 IP: 192.168

  • MySQL系列之十四 MySQL的高可用实现

    一.MHA ​对主节点进行监控,可实现自动故障转移至其它从节点:通过提升某一从节点为新的主节点,基于主从复制实现,还需要客户端配合实现,目前MHA主要支持一主多从的架构,要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器,一主二从,即一台充当master,一台充当备用master,另外一台充当从库. 1.MHA工作原理 从宕机崩溃的master保存二进制日志事件(binlog events) 识别含有最新更新的slave 应用差异的中继日志(relay log)到其他的slave 应用从

  • Ubuntu搭建Mysql+Keepalived高可用的实现(双主热备)

    Mysql5.5双机热备 实现方案 安装两台Mysql 安装Mysql5.5 sudo apt-get update apt-get install aptitude aptitude install mysql-server-5.5 或 sudo apt-cache search mariadb-server apt-get install -y mariadb-server-5.5 卸载 sudo apt-get remove mysql-* dpkg -l |grep ^rc|awk '{

  • keeplive+mysql+drbd高可用架构安装步骤

    DRBD(DistributedReplicatedBlockDevice)是一个基于块设备级别在远程服务器直接同步和镜像数据的开源软件,类似于RAID1数据镜像,通常配合keepalived.heartbeat等HA软件来实现高可用性. DRBD是一种块设备,可以被用于高可用(HA)之中.它类似于一个网络RAID-1功能,当你将数据写入本地文件系统时,数据还将会被发送到网络中另一台主机上.以相同的形式记录在一个文件系统中. 本地(master)与远程主机(backup)的保证实时同步,如果本地

  • centos7搭建hadoop2.10高可用(HA)

    本篇介绍在centos7中搭建hadoop2.10高可用集群,首先准备6台机器:2台nn(namenode);4台dn(datanode):3台jns(journalnodes) IP hostname 进程 192.168.30.141 s141 nn1(namenode),zkfc(DFSZKFailoverController),zk(QuorumPeerMain) 192.168.30.142 s142 dn(datanode), jn(journalnode),zk(QuorumPee

  • C++连接mysql数据库的两种方法小结

    现在正做一个接口,通过不同的连接字符串操作不同的数据库.要用到mysql数据库,以前没用过这个数据库,用access和sql server比较多.通过网上的一些资料和自己的摸索,大致清楚了C++连接mysql的方法.可以通过2种方法实现. 第一种方法是利用ADO连接, 第二种方法是利用mysql自己的api函数进行连接. 第一种方法可以实现我当前的需求,通过连接不同的字符串来连接不同的数据库.暂时只连接了mysql,sqlserver,oracle,access.对于access,因为它创建表的

  • MySQL之高可用架构详解

    目录 引言 MySQL高可用 一主一备: MySQL主从同步的几种模式: 总结 引言 "高可用"是互联网一个永恒的话题,先避开MySQL不谈,为了保证各种服务的高可用有几种常用的解决方案. 服务冗余:把服务部署多份,当某个节点不可用时,切换到其他节点.服务冗余对于无状态的服务是相对容易的. 服务备份:有些服务是无法同时存在多个运行时的,比如说:Nginx的反向代理,一些集群的leader节点.这时可以存在一个备份服务,处于随时待命状态. 自动切换:服务冗余之后,当某个节点不可用时,要做

  • MySQL下高可用故障转移方案MHA的超级部署教程

    MHA介绍 MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案,来保证数据库系统的高可用.在宕机的时间内(通常10-30秒内),完成故障切换,部署MHA,可避免主从一致性问题,节约购买新服务器的费用,不影响服务器性能,易安装,不改变现有部署.      还支持在线切换,从当前运行master切换到一个新的master上面,只需要很短的时间(0.5-2秒内),此时仅仅阻塞写操作,并不影响读操作,便于主机硬件维护.   在有高可用,数据一致性要求的系统上,MHA 提供了有用的功能

随机推荐