Mysql 集群

分布式理论

CAP原则

在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）
最多只能同时三个特性中的两个，三者不可兼得

• 一致性：数据在多个副本之间能够保持一致

• 可用性：系统提供的服务一直处于可用的状态，每次请求都能获得正确的响应

• 分区容错性：在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务

BASE

BASE是Basically Available（基本可用） 、Soft-state（软状态） 和Eventually Consistent（最终一致性）三个短语的缩写。
BASE理论是对CAP中AP的一个扩展：
	1.通过牺牲强一致性来获得可用性
	2.当出现故障允许部分不可用但要保证核心功能可用
	3.允许数据在一段时间内是不一致的,但最终达到一致状态

• 基本可用：分布式系统在出现故障时,允许损失部分可用功能,保证核心功能可用

• 软状态：允许系统中的数据存在中间状态（CAP 理论中的数据不一致）

• 最终一致：系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态

Mysql集群

优点：

• 性能提升：通过将负载分散到多个服务器，集群可以显著提升数据库的读、和写的性能

• 高可用性：集群模式提供冗余和故障转移机制

• 扩展性：集群可以通过添加更多节点，来水平扩展系统的容量、和处理能力

• 数据一致性：通过复制、和同步技术，集群模式可以确保数据在多个节点间的一致性

主从复制模式

一个主(Master)多从(Slave)，主负责写操作，从负责读操作，从库的数据从主库同步复制

支持一台主库同时向多台从库进行复制，从库同时也可以作为其他从服务器的主库，实现链状复制

主从复制可分为异步复制、同步复制和半同步复制三种

复制流程

1. master 记录 binary log 二进制日志

   在每个事务完成数据更新之前，master 在二进制日志记录这些改变。
   MySQL 将事务串行地写入二进制日志，完成后，master 通知存储引擎提交事务。

2. slave 将 master 的 binary log 拷贝到它自身的中继日志

   • slave 开始一个工作线程：I/O 线程

   • I/O 线程在 master 上打开一个普通的连接，然后开始 binlog dump process

   • binlog dump process 从 master 的二进制日志中读取事件

   • I/O 线程将这些事件写入中继日志

3. SQL slave 重做中继日志

   • SQL 线程从中继日志读取事件，并重放其中的事件，更新 slave 的数据，使其与 master 中的数据一致

复制种类

• 异步复制：

  • 实现：

  • 主库写 binlog、从库 I/O 线程读 binlog 并写入 relaylog、从库 SQL 线程重放事务这三步之间是异步的

  • 主库不需要关心备库的状态，主库不保证事务被传输到从库

  • 如果主库崩溃，某些事务可能还未发送到从库，切换后可能导致事务的丢失

  • 优点：可以有更高的吞吐量

  • 缺点：是不能保持数据实时一致

• 同步复制

  • 实现：

  • 主库在提交事务前，必须确认事务在所有的备库上都已经完成提交

  • 主库是最后一个提交的，在提交前需要将事务传递给从库并完成重放、提交等一系列动作

  • 优点：任何时候主备库都是一致的，主库的崩溃不会丢失事务

  • 缺点：由于主库需要等待备库先提交事务，吞吐量很低

• 半同步复制

  • 实现：
  • 主库在提交事务时先等待，必须确认至少一个从库收到了事件（从库将事件写入 relaylog，不需要重放和提交，并向主库发送一个确认信息 ACK）
  • 主库收到确认信息后才会正式提交
  • 优点：
  • 有较高的吞吐量
  • 有较好的安全性
  • 缺点：
  • 只适合在网络条件较好且地理上距离不远的环境部署，否则可能会因为网络延迟大幅降低主库性能

• GTID

是已提交事务的一个编号，是事务的全局唯一编号,由 server_uuid：sequence_Number 组成
server_uuid：是 MySQL 实例的全局唯一标识；存放在$datadir/auto.cnf。
sequence_Number：是 MySQL 内部的事务编号，在一个 MySQL 实例中不会重复。

• 实现：

• 当一个事务在主库端执行并提交时，产生 GTID，一同记录到 binlog 日志中

• binlog 传输到 slave，并存储到 slave 的 relaylog 后，读取 GTID 设置为 gtid_next 变量

• sql 线程从 relaylog 中获取 GTID，然后对比 slave 端的 binlog 是否有该 GTID

• 如果有记录，说明该 GTID 的事务已经执行，slave 会忽略

• 如果没有记录，slave 就会执行该 GTID 事务，并记录该 GTID 到自身的 binlog

• 优点：

• 可以快速的确定事务最初是在哪个实例上提交的

• 一个事务对应一个唯一ID，一个GTID在一个服务器上只会执行一次

• 不需要指定二进制文件名和位置

• 缺点：

• 主从库的表存储引擎必须一致

• 不允许一个SQL同时更新一个事务引擎和非事务引擎的表

• 不支持create table….select 语句复制

读写分离、分库分表

• 读写分离

通过主从复制实现，将写操作集中在主库（Master），读操作分散到多个从库（Slave）。

可以使用 MyCAT 、或 ShardingSphere 等中间件，来实现读写分离。

• 分库分表

垂直拆分：表数量多，将表拆到其他库
水平拆分：表记录多，将表记录拆到其他表

通过将这两种方法组合使用，可以有效地分散数据库的读写负载，同时实现水平扩展。