MySQL的cluster方案有很多官方和第三方的选择,选择多就是一种烦恼,因此,我们考虑MySQL数据库满足下三点需求,考察市面上可行的解决方案:
高可用性:主服务器故障后可自动切换到后备服务器可伸缩性:可方便通过脚本增加DB服务器负载均衡:支持手动把某公司的数据请求切换到另外的服务器,可配置哪些公司的数据服务访问哪个服务器
需要选用一种方案满足以上需求。在MySQL官方网站上参考了几种解决方案的优缺点:
综合考虑,决定采用MySQL Fabric和MySQL Cluster方案,以及另外一种较成熟的集群方案Galera Cluster进行预研。
2.MySQLCluster
简介:
MySQL Cluster 是MySQL 官方集群部署方案,它的历史较久。支持通过自动分片支持读写扩展,通过实时备份冗余数据,是可用性最高的方案,声称可做到99.999%的可用性。
架构及实现原理:
MySQL cluster主要由三种类型的服务组成:
NDB Management Server:管理服务器主要用于管理cluster中的其他类型节点(Data Node和SQL Node),通过它可以配置Node信息,启动和停止Node。 SQL Node:在MySQL Cluster中,一个SQL Node就是一个使用NDB引擎的mysql server进程,用于供外部应用提供集群数据的访问入口。Data Node:用于存储集群数据;系统会尽量将数据放在内存中。
缺点及限制:
对需要进行分片的表需要修改引擎Innodb为NDB,不需要分片的可以不修改。NDB的事务隔离级别只支持Read Committed,即一个事务在提交前,查询不到在事务内所做的修改;而Innodb支持所有的事务隔离级别,默认使用Repeatable Read,不存在这个问题。外键支持:虽然最新的Cluster版本已经支持外键,但性能有问题(因为外键所关联的记录可能在别的分片节点中),所以建议去掉所有外键。Data Node节点数据会被尽量放在内存中,对内存要求大。
数据库系统提供了四种事务隔离级别:
A.Serializable(串行化):一个事务在执行过程中完全看不到其他事务对数据库所做的更新(事务执行的时候不允许别的事务并发执行。事务串行化执行,事务只能一个接着一个地执行,而不能并发执行。)。
B.Repeatable Read(可重复读):一个事务在执行过程中可以看到其他事务已经提交的新插入的记录,但是不能看到其他其他事务对已有记录的更新。
有两种方法,一种方法使用mysql的checktable和repairtable的sql语句,另一种方法是使用MySQL提供的多个myisamchk,isamchk数据检测恢复工具。前者使用起来比较简便。推荐使用。1.checktable和repairtable登陆mysql终端:mysql-uxxxxx-pdbnamechecktabletabTest如果出现的结果说Status是OK,则不用修复,如果有Error,可以用:repairtabletabTest进行修复,修复之后可以在用checktable命令来进行检查。在新版本的phpMyAdmin里面也可以使用check/repair的功能。2.myisamchk,isamchk其中myisamchk适用于myisam类型的数据表,而isamchk适用于ISAM类型的数据表。这两条命令的主要参数相同,一般新的系统都使用myisam作为缺省的数据表类型,这里以myisamchk为例子进行说明。当发现某个数据表出现问题时可以使用:myisamchktablename.MYI进行检测,如果需要修复的话,可以使用:myisamchk-oftablename.MYI关于myisamchk的详细参数说明,可以参见它的使用帮助。需要注意的时在进行修改时必须确保MySQL服务器没有访问这个数据表,保险的情况下是最好在进行检测时把MySQL服务器Shutdown掉。-----------------------------另外可以把下面的命令放在你的rc.local里面启动MySQL服务器前:[-x/tmp/mysql.sock]&&/pathtochk/myisamchk-of/DATA_DIR/*/*.MYI其中的/tmp/mysql.sock是MySQL监听的Sock文件位置,对于使用rpm安装的用户应该是/var/lib/mysql/mysql.sock,对于使用源码安装则是/tmp/mysql.sock可以根据自己的实际情况进行变更,而pathtochk则是myisamchk所在的位置,DATA_DIR是你的MySQL数据库存放的位置。需要注意的时,如果你打算把这条命令放在你的rc.local里面,必须确认在执行这条指令时MySQL服务器必须没有启动!检测修复所有数据库(表)1. 主服务器的自动监控和故障转移MHA监控复制架构的主服务器,一旦检测到主服务器故障,就会自动进行故障转移。即使有些从服务器没有收到最新的relay log,MHA自动从最新的从服务器上识别差异的relay log并把这些日志应用到其他从服务器上,因此所有的从服务器保持一致性了。MHA通常在几秒内完成故障转移,9-12秒可以检测出主服务器故障,7-10秒内关闭故障的主服务器以避免脑裂,几秒中内应用差异的relay log到新的主服务器上,整个过程可以在10-30s内完成。还可以设置优先级指定其中的一台slave作为master的候选人。由于MHA在slaves之间修复一致性,因此可以将任何slave变成新的master,而不会发生一致性的问题,从而导致复制失败。
2. 交互式主服务器故障转移
可以只使用MHA的故障转移,而不用于监控主服务器,当主服务器故障时,人工调用MHA来进行故障故障。
3. 非交互式的主故障转移
不监控主服务器,但自动实现故障转移。这种特征适用于已经使用其他软件来监控主服务器状态,比如heartbeat来检测主服务器故障和虚拟IP地址接管,可以使用MHA来实现故障转移和slave服务器晋级为master服务器。
4. 在线切换主从服务器
在许多情况下,需要将现有的主服务器迁移到另外一台服务器上。比如主服务器硬件故障,RAID控制卡需要重建,将主服务器移到性能更好的服务器上等等。维护主服务器引起性能下降,导致停机时间至少无法写入数据。另外,阻塞或杀掉当前运行的会话会导致主主之间数据不一致的问题发生。MHA提供快速切换和优雅的阻塞写入,这个切换过程只需要0.5-2s的时间,这段时间内数据是无法写入的。在很多情况下,0.5-2s的阻塞写入是可以接受的。因此切换主服务器不需要计划分配维护时间窗口(呵呵,不需要你在夜黑风高时通宵达旦完成切换主服务器的任务)。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)