MySql 高可用架构Atlas

Atlas是由 Qihoo 360公司Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它在MySQL官方推出的MySQL-Proxy 0.8.2版本的基础上，修改了大量bug，添加了很多功能特性。目前该项目在360公司内部得到了广泛应用，很多MySQL业务已经接入了Atlas平台，每天承载的读写请求数达几十亿条。

Atlas主要功能： 
1.读写分离 
2.从库负载均衡 
3.IP过滤 
4.自动分表 
5.DBA可平滑上下线DB 
6.自动摘除宕机的DB

Atlas介绍

Atlas是一个位于应用程序与MySQL之间中间件。在后端DB看来， Atlas相当于连接它的客户端，在前端应用看来， Atlas相当于一个DB。 Atlas作为服务端与应用程序通讯，它实现了MySQL的客户端和服务端协议，同时作为客户端与MySQL通讯。它对应用程序屏蔽了DB的细节，同时为了降低MySQL负担，它还维护了连接池

Atlas相对于官方MySQL-Proxy的优势 
1.将主流程中所有Lua代码用C重写，Lua仅用于管理接口 
2.重写网络模型、线程模型 
3.实现了真正意义上的连接池 
4.优化了锁机制，性能提高数十倍

Atlas安装配置

    1. 从https://github.com/Qihoo360/Atlas/releases 页面下载最新版RPM包，然后执行： 
      sudo rpm –i Atlas-XX.el6.x86_64.rpm安装。

注： Atlas只能安装运行在64位的系统上。后端mysql版本应大于5.1，建议使用Mysql 5.6 及以上

    1. 配置文件修改 
      Atlas运行需要依赖一个配置文件（test.cnf）。在运行Atlas之前，需要对该文件进行配置。 
      Atlas的安装目录是/usr/local/mysql-proxy，进入安装目录下的conf目录，可以看到已经有一个名为test.cnf的默认配置文件，我们只需要修改里面的某些配置项 
      test.cnf
[mysql-proxy]
(必备，默认值即可)管理接口的用户名
• admin-username = user
(必备，默认值即可)管理接口的密码
• admin-password = pwd
(必备，根据实际情况配置)主库的IP和端口
• proxy-backend-addresses = 192.168.0.12:3306
(非必备，根据实际情况配置)从库的IP和端口， @后面的数字代表权重，用来作负载均衡，若省略则默认
为1，可设置多项， 用逗号分隔。如果想让主库也能分担读请求的话，只需要将主库信息加入到下面的配
置项中。
• proxy-read-only-backend-addresses = 192.168.0.13:3306,192.168.0.14:3306
(必备，根据实际情况配置)用户名与其对应的加密过的MySQL密码，密码使用PREFIX/bin目录下的加密程
序encrypt加密，用户名与密码之间用冒号分隔。 主从数据库上需要先创建该用户并设置密码（用户名和密
码在主从数据库上要一致） 。比如用户名为myuser，密码为mypwd，执行./encrypt mypwd结果为
HJBoxfRsjeI=。如果有多个用户用逗号分隔即可。则设置如下行所示：
• pwds = myuser: HJBoxfRsjeI=,myuser2:HJBoxfRsjeI=
（必备，默认值即可)Atlas的运行方式，设为true时为守护进程方式，设为false时为前台方式，一般开发
调试时设为false，线上运行时设为true
• daemon = true
(必备，默认值即可)设置Atlas的运行方式，设为true时Atlas会启动两个进程，一个为monitor，一个为
worker， monitor在worker意外退出后会自动将其重启，设为false时只有worker，没有monitor，一般开发
调试时设为false，线上运行时设为true
• keepalive = true
(必备，根据实际情况配置)工作线程数，推荐设置成系统的CPU核数的2至4倍
• event-threads = 4

(必备，默认值即可)日志级别，分为message、 warning、 critical、 error、 debug五个级别
• log-level = message
(必备，默认值即可)日志存放的路径
• log-path = /usr/local/mysql-proxy/log

(必备，根据实际情况配置)SQL日志的开关，可设置为OFF、 ON、 REALTIME，OFF代表不记录
SQL日志，ON代表记录SQL日志，该模式下日志刷新是基于缓冲区的，当日志填满缓冲区后，
才将日志信息刷到磁盘。 REALTIME用于调试，代表记录SQL日志且实时写入磁盘，默认为OFF
• sql-log = OFF
(可选项，可不设置）慢日志输出设置。当设置了该参数时，则日志只输出执行时间超过sql-logslow（单位：ms)的日志记录。不设置该参数则输出全部日志。
• sql-log-slow = 10
(可选项，可不设置）关闭不活跃的客户端连接设置。当设置了该参数时，Atlas会主动关闭经过
‘wait-timeout‘时间后一直未活跃的连接。单位：秒
wait-timeout = 10
(必备，默认值即可)Atlas监听的工作接口IP和端口
proxy-address = 0.0.0.0:1234
(必备，默认值即可)Atlas监听的管理接口IP和端口 admin-address = 0.0.0.0:2345
(可选项，可不设置)默认字符集，若不设置该项，则默认字符集为latin1
charset = utf8
(可选项，可不设置)允许连接Atlas的客户端的IP，可以是精确IP，也可以是IP段，以逗
号分隔，若不设置该项则允许所有IP连接，否则只允许列表中的IP连接
client-ips = 127.0.0.1, 192.168.0.1

　　

运行Atlas 
进入/usr/local/mysql-proxy/bin目录，执行下面的命令启动、重启或停止Atlas。 
(1). sudo ./mysql-proxyd test start，启动Atlas。 
(2). sudo ./mysql-proxyd test restart，重启Atlas。 
(3). sudo ./mysql-proxyd test stop，停止Atlas。 
执行命令：mysql -h127.0.0.1 -P1234 -u用户名 -p密码，如果能连上则证明Atlas初步 
测试正常，可以再尝试发几条SQL语句看看执行结果是否正确。

Atlas读写分离

Atlas后端连接的MySQL主库的IP和端口，可设置多项，用逗号分隔 
例如 
proxy-backend-addresses = 192.168.237.128:3308

Atlas后端连接的MySQL从库的IP和端口，@后面的数字代表权重，用来作负载均衡，若省略则默认为1，可设置多项，用逗号分隔 
proxy-read-only-backend-addresses = 192.168.237.130:[email protected]

关闭主备库复制关系，在主库上查看

当MySQL主库关闭的情况下，写操作失败，读操作依然可以执行 
当MySQL仅有的一个从库关闭的情况下，写操作成功，读操作也漂移到主库上执行

Atlas负载均衡

当有多个从库的情况下 
Atlas后端连接的MySQL主库的IP和端口，可设置多项，用逗号分隔 
proxy-backend-addresses = 192.168.237.128:3308 
Atlas后端连接的MySQL从库的IP和端口，@后面的数字代表权重（数字越大读取的机会更高），用来作负载均衡，若省略则默认为1，可设置多项，用逗号分隔

例如：

proxy-read-only-backend-addresses =192.168.237.130:[email protected],192.168.237.131:[email protected]

　　

当第一个从库崩溃时执行查询语句，语句都在第二个节点查询

当有多个读节点时，权重越大，被读取的可能性就越高

Atlas后端连接的MySQL从库的IP和端口， @后面的数字代表权重，用来作负载均衡，若省略则默认为1， 
可设置多项，用逗号分隔

例：

proxy-read-only-backend-addresses = 192.168.237.130:[email protected]1,192.168.237.131:[email protected]2

自动读写分离挺好，但有时候写完马上就想读，万一主从同步延迟怎么办? 
SQL语句前增加 /*master*/ 就可以将读请求强制发往主库。在mysql命令行测试该功能时，需要加-c选项，以防mysql客户端过滤掉注释信息。

主库宕机，读操作受影响么？ 
在Atlas中读操作不受影响，Atlas会将读请求转发到其他还存活的从库上。但此时写请求将会失败，因为主库宕机了。

Altas支持多个主库的运行模式吗？ 
官网：目前还未对于Atlas后面挂接多个主库的情形进行测试过，不建议这样使用。建议使用一主一从或一主多从的模式。 
可以做双主，在proxy-backend-addresses = ip1,ip2 但是不建议使用

Atlas分表功能

类似在一个库，创建了多个子表

使用Atlas的分表功能时，首先需要在配置文件（test.cnf）设置tables参数。

tables参数设置格式：数据库名.表名.分表字段.子表数量，比如你的数据库名叫school，表名叫stu，分表字段叫id，总共分为100张表，那么就写为school.stu.id.100，如果还有其他的分表，以逗号分隔即可。用户 
需要在数据库手动建立100张子表（stu_0,stu_1,…stu_99，注意子表序号是从0开始的）。 且所有的子表必须在DB的同一个database里·

分表的效果是： 
当通过Atlas执行（SELECT、 DELETE、 UPDATE、 INSERT、 REPLACE）操作时， 
Atlas会根据分表字段结果（id%100=k），定位到相应的子表（stu_k）。 
例如，执行 
select * from stu where id=110;，Atlas会自动从stu_10这张子表返回查询结果。 
但如果执行SQL语句（select * from stu;）时不带上id，则会提示执行stu 表不存在。

Atlas暂不支持自动建表和跨库分表的功能 
Atlas目前支持分表的语句有SELECT、 DELETE、 UPDATE、 INSERT、 REPLACE

需要安装非shard版本，sharding版本不支持分表功能 
分表设置，此例中person为库名，mt为表名，id为分表字段，3为子表数量，可设置多项，以逗号分隔，若不分表则不需要设置该项

局限性： 
应用程序连接atlas分表的时候，查询必须要加where 条件 ，分表字段= 不能用范围查询>,<,或者between and ，不支持全表查询。

例：

mysql> select * from students where id=0;
Empty set (0.00 sec)
mysql> select * from students;
ERROR 1146 (42S02): Table ‘test.students‘ doesn‘t exist
mysql> select * from students where id>2;
ERROR 1146 (42S02): Table ‘test.students‘ doesn‘t exist

　　

Atlas 分片

Sharding当前是Atlas的分布式分支, 是Atlas最近重点开发的功能. Sharding的基本思想 
就是把一个数据表中的数据切分成多个部分, 存放到不同的主机上去(切分的策略有多种),从而缓解单台机器的性能跟容量的问题. sharding是一种水平切分, 适用于单表数据庞大的情景

Atlas以表为单位sharding, 同一个数据库内可以同时共有sharding的表和不sharding的表, 不sharding的表数据存在未sharding的数据库组中.

目前Atlas sharding支持insert, delete, select, update语句, 所有的写操作如insert,delete, update只能一次命中一个组, 否则会报”ERROR 1105 (HY000):write operationis only allow to one dbgroup!”错误.

Sharding数据库组

在Atlas中, 将一个组看做是数据存储的单位,一个组由一台master, 零台或者多台slave组成(mysql主从同步需要由用户自己配置). 每个组之间的数据独立, 没有关系, 表的数据的各个部分存储在各个组中.

组内读写分离

与非sharding的方案一样,Atlas sharding也支持组内的读写分离, 也就是说Atlas在命中了某个组之后, 还是会对这个组内的master和slave执行读写分离(读发送到slave, 写发送到master)

Sharding 数据切分策略

Range 方式 
范围数据切分方式，比如 
shard Key范围在0-1000的数据存放在Group0中, 
范围在1000-2000的数据存放在Group1中, 
2000-MaxInt 的数据存放在Group2 中. 
这些范围的大小不需要相同.比如id为shard key的话, sql: “select * from test where id = 1500;”, 
Atlas会将此语句发往Group1. 暂时Atlas的range是静态的, 不支持动态的增加范围

hash 方式 
目前Atlas使用取模的方式实现Hash, 也就是说Hash(id) = id % group_count, 如id =10, id % 3 = 1, 所以会命中到DbGroup1中.

Atlas sharding部分新增配置项，包含两个部分： 
shardrule. 一个shardrule对应一个分表规则，不同的shardrule通过下划线后面的数字区分。

例如shardrule-0, shardrule-1….。 
一个shardrule里面有以下几项：

[shardrule-0]
table = test.sharding_test #分表名，由数据库+表名组成
type = range #sharding类型：range 或 hash
shard-key = id #sharding 字段
groups = 0:0-999,1:1000-1999 #分片的group，
如果是range类型的sharding，则groups的格式是：group_id:id范围。
如果是hash类型的sharding，则groups的格式是：group_id。例如groups = 0, 1
group. 一个group一般包含一主多从，由master（proxy-backend-addresses）和
slave（proxy-read-only-backend-addresses）组成。 group之间的区别也是通过下
划线后面的数字区分。

　　

假设我们有以下一个sharding的表, 建表语句如下:

DROP TABLE IF EXISTS `sharding_test`;
CREATE TABLE `sharding_test` ( `id` int(11) NOT NULL AUTO_INCREMENT,
`name` char(50) COLLATE utf8_bin NOT NULL,
`age` int(11) DEFAULT NULL,
`birthday` date DEFAULT NULL,
`nickname` char(50) COLLATE utf8_bin DEFAULT NULL,
PRIMARY KEY (`id`) );

　　

有两个dbgroup(数据库组), 每个dbgroup有一个master, sharding_test使用range的方 
式, 以id作为shard key, 属于test数据库, dbgroup0属于范围0 - 999, dbgroup1 属于 
范围 1000 - 1999

dbgroup0 有一主, 192.168.237.130:3308 
dbgroup1 有一主, 192.168.237.131:3308

[mysql-proxy]
admin-username = user
admin-password = pwd
#Atlas后端连接的MySQL主库的IP和端口，可设置多项，用逗号分隔
proxy-backend-addresses = 192.168.237.128:3308
#proxy-read-only-backend-addresses = 192.168.237.130:[email protected],192.168.237.131:[email protected]
daemon = true
keepalive = false
event-threads = 4
log-level = debug
log-path = /usr/local/mysql-proxy/log
sql-log = realtime
proxy-address = 0.0.0.0:1234
admin-address = 0.0.0.0:2345
charset = UTF8
wait-timeout = 3600
pwds = root:S4HJu78/H/6I/aYp2Xdb8Q==
[shardrule-0]
table = test3.sharding_test
type = range
shard-key = id
groups = 0:0-999,1:1000-1999
[group-0]
# master
proxy-backend-addresses=192.168.237.130:3308
# slave
#proxy-read-only-backend-addresses=127.0.0.1:3308
[group-1]
proxy-backend-addresses=192.168.237.131:3308
#proxy-read-only-backend-addresses=127.0.0.1:3310

　　

运行Atlas 
进入/usr/local/mysql-proxy/bin目录，执行下面的命令启动、重启或停止Atlas。 
(1). sudo ./mysql-proxyd test start，启动Atlas。 
(2). sudo ./mysql-proxyd test restart，重启Atlas。 
(3). sudo ./mysql-proxyd test stop，停止Atlas

执行命令： mysql -h 127.0.0.1 -P 1234 -u 用户名 -p，如果能连上则证明Atlas初步 
测试正常，可以再尝试发几条SQL语句看看执行结果是否正确。

关于支持的语句

Atlas sharding只对sql语句提供有限的支持, 目前支持基本的Select, insert/replace, delete, update语句, 支持全部的Where语法(SQL-92标准), 不支持DDL(create drop alter)以及一些管理语句, DDL请直连MYSQL执行, 请只在Atlas上执行Select, insert, delete, update(CRUD)语句

对于以下语句, 如果语句命中了多台dbgroup, Atlas均未做支持(如果语句只命中了一个dbgroup, 如select count(*) from test where id < 1000, 其中dbgroup0范围是0 - 1000, 那么这些特性都是支持的) 
Limit Offset (支持Limit 同一个dbgroup) 
Order by 
Group by 
Join 
count, Max, Min等函数不支持

子查询在Sharding中可能会返回不正确的结果, 也请不要使用子查询. 请把语句拆分成多句执行 
对于写操作, 如果写操作命中了多个数据库组, 由于部分成功(某个组执行失败)需要回滚的问题, 暂时不支持写操作命中多个数据组的语句.请拆分成多个sql语句执行

Atlas可能会在接下来的版本中对其中的一些特性中做出支持.

例用Atlas插入几条数据，做一下测试:

$ mysql -h127.0.0.1 -P1234 -uroot -pmysqltest -c
mysql> use test3;
Database changed
mysql> insert into sharding_test(id, name, age) values(1, ‘test‘, 0);
Query OK, 1 row affected (0.00 sec)
mysql> insert into sharding_test(id, name, age) values(50, ‘test‘, 0), (999, ‘test‘, 0);
Query OK, 2 rows affected (0.00 sec)

　　

以上几条数据都插入到了dbgroup0, 请注意第二条多值插入的语句, 因为50和999都命中了dbgroup0, 所以其执行成功, 但是如果执行以下的语句:

mysql> insert into sharding_test(id, name, age) values(100, ‘test‘, 0), (1500, ‘test‘,
0);
ERROR 1105 (HY000): Proxy Warning - write operation is only allow to one

　　

dbgroup! 在sharding的表中, 这是不允许的, 因为id为100命中了dbgroup0, 而id为1500 命中了dbgroup1, 由于分布式的多值插入可能导致部分成功, 需要回滚, 这个Atlas暂不支持. update, delete, replace同理.

再插几条数据到dbgroup1:

mysql> insert into sharding_test(id, name, age) values(1000, ‘test‘, 0), (1999,
‘test‘, 0);
Query OK, 2 rows affected (0.00 sec)
mysql> select * from sharding_test;
+------+------+------+----------+----------+
| id | name | age | birthday | nickname |
+------+------+------+----------+----------+
| 1 | test | 0 | NULL | NULL |
| 50 | test | 0 | NULL | NULL |
| 999 | test | 0 | NULL | NULL |
| 1000 | test | 0 | NULL | NULL |
| 1999 | test | 0 | NULL | NULL |

mysql> select * from sharding_test where id>50;
+------+------+------+----------+----------+
| id | name | age | birthday | nickname |
+------+------+------+----------+----------+
| 999 | test | 0 | NULL | NULL |
| 1000 | test | 0 | NULL | NULL |
| 1999 | test | 0 | NULL | NULL |

#JOIN操作，不支持
mysql> select * from sharding_test a,test.temp b on a.id=b.id;
ERROR 1105 (sqlst): Proxy Warning - Sharing Hit Multi Dbgroup Not Support
SQL

#update操作
mysql> update sharding_test set name=‘test2‘;
ERROR 1105 (HY000): Proxy Warning - Syntax Forbidden!
mysql> update sharding_test set name=‘test2‘ where id<2000;
ERROR 1105 (sqlst): Proxy Warning - write operation is only allow to one
dbgroup!
mysql> update sharding_test set name=‘test2‘ where id<999;
Query OK, 2 rows affected (0.01 sec)

#delete操作
mysql> delete from sharding_test;
ERROR 1105 (HY000): Proxy Warning - Syntax Forbidden!
mysql> delete from sharding_test where id<2000;
ERROR 1105 (sqlst): Proxy Warning - write operation is only allow to one
dbgroup!
mysql> delete from sharding_test where id>1900;
Query OK, 1 row affected (0.01 sec)

　　

更多的看看官方文档:https://github.com/Qihoo360/Atlas/wiki

原文地址：https://www.cnblogs.com/yangjian1/p/9772633.html

时间： 2024-10-08 19:55:19

MySql 高可用架构Atlas的相关文章

15、 Heartbeat+DRBD+MySQL高可用架构方案与实施过程细节

15. Heartbeat+DRBD+MySQL高可用架构方案与实施过程细节 参考自:http://oldboy.blog.51cto.com/2561410/1240412 heartbeat和keepalived应用场景及区别 很多网友说为什么不使用keepalived而使用长期不更新的heartbeat,下面说一下它们之间的应用场景及区别: 1.对于web,db,负载均衡(lvs,haproxy,nginx)等,heartbeat和keepalived都可以实现 2.lvs最好和keepa

MySQL 高可用架构在业务层面的应用分析

MySQL 高可用架构在业务层面的应用分析 http://mp.weixin.qq.com/s?__biz=MzAxNjAzMTQyMA==&mid=208312443&idx=1&sn=f9a0d03dd9a1cf3b3575c0241291e421&scene=22&srcid=seLU5tmZumKLzwVBIHzM#rd http://mp.weixin.qq.com/s?__biz=MzAxNjAzMTQyMA==&mid=208312443&am

MySQL高可用架构之MHA （未完，待续）

MySQL高可用架构之MHA 简介: MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能在最大程度上保证数据的一致性,以达到真正意义上的高可用. 该软件由两部分组成:

mysql高可用架构谁能提供具体实践实例！！！

mysql高可用架构目前只查到4中解决方案,如下所示,但是没有具体实践,看到本博客的大神们,能不能给我提供一些实践的实例,谢谢!!!!! 1  Lvs+keeplived+mysql 的方案 单点写入读负载均衡主主同步高可用方案 2 Heartbeat 高可用MySQL 主主同步方案 3 Heartbeat+DRBD+mysql 高可用方案 4 MMM 高可用 mysql 方案

整个MHA+keepalived+lvs+mysql高可用架构配置说明

整个MHA+keepalived+lvs+mysql高可用架构配置说明1.1. 环境简介1.1.1.vmvare虚拟机,系统版本CentOS7.5 x86_64位最小化安装,mysql的版本5.7.21,1.1.2.虚拟机器的ssh端口均为默认22,1.1.3.虚拟机的iptables全部关闭,1.1.4.虚拟机的selinux全部关闭,1.1.5.虚拟机服务器时间全部一致 ntpdate 0.asia.pool.ntp.org1.1.6.3台机器的ssh端口为22**1.2.此次试验采用的是3

mysql高可用架构设计

主要介绍:复制功能介绍.mysql二进制日志.mysql复制拓扑.高可用框架.单点故障.读写分离和负载均衡介绍等 mysql复制功能提供分担读负载 复制解决的问题 实现在不同服务器上的数据分布 利用二进制日志增量进行 不需要太多的带宽 但是使用基于行的复制在进行大批量的更改时会对带宽带来一定得压力,特别是跨IDC环境下进行复制 实现在不同服务器上的数据分布 实现数据读取的负载均衡 需要其他组件配合完成 利用DNS轮询的方式把程序的读连接到不同的备份数据库, 使用LVS,haproxy这样的代理方

探索MySQL高可用架构之MHA(6)

-----构建mysql高可用系列(共9篇) 上一篇文章介绍了本次架构的Atlas读写分离! 本篇文章主要介绍本次架构中的keepalive部分! 什么是Keepalived呢???? keepalived是一款c语言写的实现在linux系统上实现负载均衡和高可用的软件.它遵从于GNU是一款优秀的开源软件.keepalived观其名可知,保持存活,在网络里面就是保持在线了,也就是所谓的高可用或热备,用来防止单点故障的发生. 两个关键词的解释 负载均衡 keepalived内置了对ipvs函数的调

探索MySQL高可用架构之MHA(5)

-----构建mysql高可用系列(共9篇) 上一篇文章介绍了本次架构的AB复制操作! 本篇文章主要介绍本次架构中的Atlas读写分离! 为什么要分库.分表.读写分离? 现在大型的电子商务系统,在数据库层面大都采用读写分离技术,就是一个Master数据库,多个Slave数据库. Master库负责数据更新,Slave库当然负责非实时数据查询. 因为在实际的应用中,数据库都是读多写少(读取数据的频率高,更新数据的频率相对较少),而读取数据通常耗时比较长,占用数据库服务器的CPU较多,从而影响用户体

探索MySQL高可用架构之MHA(7)

-----构建mysql高可用系列(共9篇) 上一篇文章介绍了本次架构的keepalive读写分离! 本篇文章主要介绍本次架构中的mha安装部分! 关于MHA MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本DeNA公司youshimaton(现就职于 Facebook公司)开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件.在MySQL故障切换过程中,MHA能做到在 0~30秒之内自动完成数据库的故