MariaDB知识点总结03--从主+多主集群

一.从主架构

1.从主复制原理

从库生成两个线程,一个I/O线程,一个SQL线程;

i/o线程去请求主库 的binlog,并将得到的binlog日志写到relay log(中继日志) 文件中;
主库会生成一个 log dump 线程,用来给从库 i/o线程传binlog;

SQL 线程,会读取relay log文件中的日志,并解析成具体操作,来实现主从的操作一致,而最终数据一致;

2.主从架构特点

主从多用于网站架构,因为主从的同步机制是异步的,数据的同步有一定延迟,也就是说有可能会造成数据的丢失,但是性能比较好,

因此网站大多数用的是主从架构的数据库,读写分离必须基于主从架构来搭建。

(1).读写分离并实现负载均衡

主从架构如何实现读写分离?需要通过mycat读写分离器来设置,当从客户端发出写权限的SQL语句(如:delete等)时,mycat会将其转发给主数据库;

当从客户端发出读权限的SQL语句(如:select等)时,mycat会将其转发给从数据库。这样就实现了主从库的读写分离,避免主数据库的负载过大。

同时当一主多从架构,为了实现从数据库的负载均衡,可以在mycat上再添上LVS,将读权限的语句请求根据算法转发到从数据库上。

(2).如何预防单点故障(主数据库宕机了。。)

方案一:MHA监控

 工作原理:

MHA通过部署在主从集群上的node节点,时刻监控集群上的master节点,当master宕机了,那么MHA会立刻从集群中选出一个从节点来

顶替主节点。从而实现集群的高可用即预防单点故障。

方案二:主主架构

即互为主备,互相监控对方的二进制日志文件进行同步。不过这种方式要注意:可能会出现数据不一致情况。

因为同步是异步同步,可能没有及时同步数据,导致数据不一致。

当然可以给每台主机采用keepalived实现高可用(使用VIP对外提供服务)

建议采用高可用策略的时候,masterA或masterB均不因宕机恢复后而抢占VIP(非抢占模式);

二.多主架构(galera集群)

1.主要功能

同步复制

真正的multi-master,即所有节点可以同时读写数据库

自动的节点成员控制,失效节点自动被清除

新节点加入数据自动复制

真正的并行复制,行级

用户可以直接连接集群,使用感受上与MySQL完全一致

2.优势

因为是多主,所以不存在Slavelag(延迟)

不存在丢失事务的情况

同时具有读和写的扩展能力

更小的客户端延迟

节点间数据是同步的,而Master/Slave模式是异步的,不同slave上的binlog可能是不同的

 3.工作原理(wsrep)

Galera集群的复制功能基于Galeralibrary实现,为了让MySQL与Galera library通讯,特别针对MySQL开发了wsrep API。

Galera插件保证集群同步数据,保持数据的一致性,靠的就是可认证的复制,工作原理如下图:

当客户端发出一个commit的指令,在事务被提交之前,所有对数据库的更改都会被 write-set 收集起来,并且将 write-set 纪录的内容发送给其他节点。

write-set 将在每个节点进行认证测试,测试结果决定着节点是否应用write-set更改数据。

如果认证测试失败,节点将丢弃 write-set ;如果认证测试成功,则事务提交。

原文地址:https://www.cnblogs.com/Super-It/p/11431587.html