标签：图片 读写分离 mariadb 其他 ast style keepalive src mysql
一.从主架构
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 ；如果认证测试成功，则事务提交。
标签：图片 读写分离 mariadb 其他 ast style keepalive src mysql
原文地址：https://www.cnblogs.com/Super-It/p/11431587.html
