Chinaunix首页 | 论坛 | 博客
  • 博客访问: 13340
  • 博文数量: 14
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 85
  • 用 户 组: 普通用户
  • 注册时间: 2017-06-26 17:35
文章分类

全部博文(14)

文章存档

2017年(14)

我的朋友

分类: 网络与安全

2017-07-05 15:17:47

作者介绍

王松磊,现任职于UCloud,从事MySQL数据库内核研发工作。主要负责UCloud云数据库udb的内核故障排查工作以及数据库新特性的研发工作。

 

一、概述

 

我们在考虑MySQL数据库的高可用架构时,主要考虑如下几方面:

 

  1. 如果数据库发生了宕机或者意外中断等故障,能尽快恢复数据库的可用性,尽可能的减少停机时间,保证业务不会因为数据库的故障而中断。

  2. 用作备份、只读副本等功能的非主节点的数据应该和主节点的数据实时或者最终保持一致。

  3. 当业务发生数据库切换时,切换前后的数据库内容应当一致,不会因为数据缺失或者数据不一致而影响业务。

 

关于对高可用的分级我们暂不做详细的讨论,这里只讨论常用高可用方案的优缺点以及选型。

 

二、高可用方案

 

1、主从或主主半同步复制

 

使用双节点数据库,搭建单向或者双向的半同步复制。在5.7以后的版本中,由于lossless replication、logical多线程复制等一些列新特性的引入,使得MySQL原生半同步复制更加可靠。

 

常见架构如下:

 

 

 

通常会和Proxy、Keepalived等第三方软件同时使用,即可以用来监控数据库的健康,又可以执行一系列管理命令。如果主库发生故障,切换到备库后仍然可以继续使用数据库。

 

优点:

  • 架构比较简单,使用原生半同步复制作为数据同步的依据

  • 双节点,没有主机宕机后的选主问题,直接切换即可

  • 双节点,需求资源少,部署简单

 

缺点:

  • 完全依赖于半同步复制,如果半同步复制退化为异步复制,数据一致性无法得到保证

  • 需要额外考虑HAProxy、Keepalived的高可用机制

阅读(519) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~