PXC简介:
galera产品是以galera cluster方式为 mysql 提高高可用集群解决方案的。galera cluster就是集成了galera插件的mysql集群。galera replication是codership提供的mysql数据同步方案,具有高可用性,方便扩展,并且可以实现多个mysql节点间的数据同步复制与读写,可保障数据库的服务高可用及数据强一致性。
PXC属于一套近乎完美的mysql高可用集群解决方案,相比那些比较传统的基于主从复制模式的集群架构MHA和MM+keepalived,galera cluster最突出特点就是解决了诟病已久的数据复制延迟问题,基本上可以达到实时同步。而且节点与节点之间,他们相互的关系是对等的。本身galera cluster也是一种多主架构。galera cluster最关注的是数据的一致性,对待事物的行为时,要么在所有节点上执行,要么都不执行,它的实现机制决定了它对待一致性的行为非常严格,这也能非常完美的保证MySQL集群的数据一致性;
对galera cluster的封装有两个,虽然名称不同,但实质都是一样的,使用的都是galera cluster。一个MySQL的创始人在自己全新的MariaDB上实现的MAriaDB cluster;一个是著名的MySQL服务和 工具 提供商percona实现的percona xtradb cluster,简称PXC
要搭建PXC架构至少需要3个mysql实例来组成一个集群,三个实例之间不是主从模式,而是各自为主,所以三者是对等关系,不分从属,这就叫multi-master架构。客户端写入和读取数据时,连接哪个实例都是一样的。读取到的数据时相同的,写入任意一个实例之后,集群自己会将新写入的数据同步到其他实例上,这种架构不共享任何数据,是一种高冗余架构。
--:galera cluster的功能有7点,如下:
①:多主架构:真正的多点读写集群,在任何时候读写的数据都是最新的;
②:同步复制:集群不同节点之间的数据同步,没有延迟,在数据库挂掉之后,数据不会丢失;
③:并发复制:从节点在apply数据时,支持并行执行,有更好的性能表现
④:故障切换:因为支持多点写入,所以在出现数据库故障时可以很容易的进行故障切换
⑤:热插拔:在服务期间,如果数据库挂了,只要监控程序发现的够快,不可服务时间就会非常少,在节点故障期间,节点本身对集群的影响非常小;
⑥:自动节点克隆:在新增节点或停机维护时,增量数据或基础数据不需要人工手动备份提供,galera cluster会自动拉取在线节点数据,集群最终会变为一致;
⑦:对应用透明:集群的维护,对应用程序是透明的,几乎感觉不到;
--PXC原理:
PXC最常使用以下4个端口号:
3306-数据库对外服务的端口号。
4444-请求SST的端口(SST是指数据库一个备份全量文件的传输。)
4567-组成员之间进行沟通的一个端口号
4568-用于传输IST(相对于SST来说的一个增量)
PXC的操作流程:
首先客户端先发起一个事务,该事务先在本地执行,执行完成之后就要发起对事务的提交操作了。在提交之前需要将产生的复制写集广播出去,然后获取到一个全局的事务ID号,一并传送到另一个节点上面。通过合并数据之后,发现没有冲突数据,执行apply_cd和commit_cb动作,否则就需要取消此次事务的操作。而当前server节点通过验证之后,执行提交操作,并返回OK,如果验证没通过,则执行回滚。当然在生产中至少要有3个节点的集群环境,如果其中一个节点没有验证通过,出现了数据冲突,那么此时采取的方式就是讲出现不一致的节点踢出集群环境,而且它自己会执行shutdown命令,自动关机。
PXC的优点:
①:实现mysql数据库集群架构的高可用性和数据的 强一致性。
②:完成了真正的多节点读写的集群方案。
③:改善了传统意义上的主从复制延迟问题,基本上达到了实时同步。
④:新加入的节点可以自动部署,无须提供手动备份,维护起来很方便。
⑤:由于是多节点写入,所以数据库故障切换很容易。
PXC的缺点:
①:新加入的节点开销大,需要复制完整的数据。采用SST传输开销太大。
②:任何更新事务都需要全局验证通过,才会在每个节点库上执行。集群性能受限于性能最差的节点,也就是经常说的短板效应。
③:因为需要保证数据的一致性,所以在多节点并发写时,锁冲突问题比较严重。
④:存在写扩大问题,所有的节点上都会发生些操作。
⑤:只支持innodb存储引擎的表。
⑥:没有表级别的锁定,执行DDL语句操作会把整个集群锁住,而且也 kill 不了(建议使用Osc操作,即在线DDL)
⑦:所有的表必须含有主键,不然操作数据时会报错。
PXC搭建的注意点:
首先要规范集群中节点的数量,整个集群中节点数控制在最少3个、最多8个范围内。最少3个节点是为了防止出现脑裂现象,因为只有在两个节点下才会出现此现象。脑裂现象的标志就是输入任何命令、返回结果都是unkown command,节点在集群中,会因为新节点的加入或者故障,同步失效等而发生状态的切换。
--节点状态变化阶段:
open:节点启动成功,尝试连接到集群。
primary:节点已处于集群中,在新节点加入时,选取donor进行数据同步时会产生的状态。
joiner:节点处于等待接收同步文件时的状态。
joined:节点完成数据同步的工作,尝试保持和集群进度一致。
synced:节点正常提供服务的状态,表示已经同步完成并和集群进度保持一致。
doner:节点处于为新加入的节点提供全量数据时的状态。
注意:doner节点就是数据的贡献者,如果一个新节点加入集群,此时又需要大量数据的SST传输,就有可能因此而拖垮整个集群的性能。所以在生产环境中,如果数据量小,还可以使用SST全量传输,但如果数据量很大就不建议使用这种方式了。可以考虑先建立主从关系,在加入集群。
PXC有两种节点的数据传输方式:一种叫SST全量传输,另一种叫IST增量传输。
SST传输有:xtrabackup、mysqldump和rsync三种方法。而增量传输就一种方法就是xtrabackup。但生产环境中一般数据量不大的时候,可以使用SST全量传输,但也只实现xtrabackup方法。
在PXC中还有一个特别重要的模块就是GCache。它的核心功能就是每个节点缓存当前最新的写集。如果有新节点加入进来,就可以把新数据的增量传递给新节点,而不需要再使用SST方式了。这样可以让节点更快地加入集群中。涉及参数如下:
gcache.size:代表用来缓存写集增量信息的大小。它的默认大小是128MB,通过wsrep_provider_options参数设置。建议调整为2GB-4GB范围,足够的空间便于缓存更多的增量信息。
gcache.mem_size:代表gcache中内存缓存的大小,适度调大可以提高整个集群的性能。
gcache.page_size:可以理解为如果内存不够用(gcache不足),就直接将写集写入磁盘文件中。
--:PXC的工作模式:
galera的工作模式是——某个节点写入一个事务,它会广播到其他节点,而这个所谓的其他节点,也包括自己。也就说自己发出来的事务,自己也会收到,只是在收到并产生GTID之后,就被简单忽略了,而不会再去apply一次。
--:galera的并发控制机制:
并发控制主要是在接口galera_pre_commit中完成的,这个接口是galera最重要的接口之一,这里面实现了最重要的复制、验证逻辑。目前,这个接口中包括的并发控制有以下几点:
①:数据复制:
目前的galera版本中,写集数据的发送是通过asio的异步方式将数据广播出去。这个发送是串行的,是一个临界区,因为在每次 发送前,逻辑上还需要分片,并且每次发送完成之后,需要等待一个GTID的值,所以为了保证数据的一致性,这个发送操作需要串行;
②:写集验证:
要求所有进入处理区的GTID必须是顺序的,因为GTID是顺序产生的,所以在顺序的基础上,同一时间必须只有一个事务可以进行处理,说白了就是串行;
受这种层次并发控制管理的操作主要有验证操作,因此说验证是串行的;
③:写集apply
④:事务commit
这个层次的并发控制机制,默认是3,建议也是3,就是串行提交,这样就保证了不管在主库还是从库,所有的节点产生的binlog都是完全相同的;
3、galera 接口:
---galera_init:
这个接口的作用是初始化一个galera节点,这是一个PXC节点调用的第一个wsrep接口,在启动服务器的时候初始化,将所有需要的参数和环境变量初始化。(如:集群名字,实例地址、需要这个接口做binlog的复制等)
---galera_connect:
这个接口是第二个调用的接口。这个接口的作用是将当前节点加入集群中。加入集群前会调用函数wsrep_view_handler_cb来判断新加入节点与集群的数据是否同步;
---galera_recv:
这个接口的作用是,在这个函数里阻塞式的接收其他节点及本节点发送的数据,并且调用复制apply函数执行复制操作。(这个接口实际上是可以并行存在的。它对应的是参数wsrep_slave_threads有多少个线程,就有多少个galera_recv的调用)
---galera_pre_commit:
这个接口是galera最重要的接口之一。它的作用包括两部分,首先是将当前指定的事务写集广播给整个集群节点,然后就是验证,如果验证成功,则将处理权交给上层,继续做数据库事务的提交操作;这个接口是在数据库事务提交时调用的,调用这个接口时,必须是本地事务已经执行完成;
---galera_replay_trx:
这个接口的作用及使用,就是在验证过程中,由于数据库锁的冲突,当前操作被其他线程自治县了galera_abort_pre_com_mit,导致当前线程被强制中止,但是由于写集已经复制到其他节点,所以本节点这个事务必须要完成。通过这个接口,将这个事务的写集做一次apply,所以就叫replay;
---galera_append_key:
这个接口就是所谓的galera验证,被验证的对象实际上就是写集,而构成写集的内容,其实就是通过这个接口来完成的;
---galera_append_data:
这个接口是当前事务所生成的binlog内容,也就是说key在验证通过之后,使用data在从节点执行,即可做到数据同步;
---galera_post_commit:
这个接口是用来真正提交事务的。这个接口包括4个功能:更新状态参数wsrep_last_committed的值,表示当前事务已经真正提交了;更新参数wsrep_local_commits的值,表示本地又成功提交了一个事务;检查当前验证写集缓冲区是不是可以做purge操作;
---galera_to_execute_start:
这个接口专门用来处理DDL语句的执行;
---galera_to_execute_end:
这个接口实际上和galera_post_commit功能一样,成对出现,是为处理不同语句而设置的,主要就是为了从commit临界区中出来,从而让其他事务继续提交;
Linux公社的RSS地址 : https://www.linuxidc.com/rssFeed.aspx
本文永久更新链接地址: https://www.linuxidc.com/Linux/2018-11/155502.htm
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- 构建生产环境可用的高可用kubernetes集群
- 维基百科 – Sparql查询获取dbpedia可用的所有可用电影
- 可用性高达5个9!支付系统高可用架构设计实战
- 浪潮InCloud OpenStack:度量可用性“三维”,实现高可用云环境
- 你以为的MongoDB副本集的高可用是真的高可用了吗?
- 如何建设高可用系统
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。