MySQL复制
This commit is contained in:
罗祥
parent
9b1340bf6d
commit
1aacb86152
@ -2,7 +2,26 @@
|
||||
|
||||
## 一、PXC 集群
|
||||
|
||||
## 二、创建PXC集群
|
||||
Percona XtraDB Cluster (简称 PXC) 是 Percona 公司开源的实现 MySQL 高可用的解决方案。它将 Percona Server 和 Percona XtraBackup 与 Galera 库集成，以实现多主同步复制。和 MySQL 传统的异步复制相比，它能够保证数据的强一致性，在任何时刻集群中任意节点上的数据状态都是完全一致的，并且整个架构实现了去中心化，所有节点都是对等的，即允许你在任意节点上进行写入和读取，集群会把数据状态同步至其他所有节点。但目前 PXC 集群只支持 InnoDB 存储引擎，并具有以下限制：
|
||||
|
||||
+ 添加新节点时，必须从现有节点之一复制完整数据集。如果是 100GB，则复制 100GB。为了减少网络开销，建议在搭建集群前使用备份的方式将所有节点的数据状态调整至一致。
|
||||
+ 不支持 LOCK TABLES ，在多主设置的情况下也不受支持 UNLOCK TABLES。
|
||||
+ 不支持锁定功能，如 GET_LOCK()，RELEASE_LOCK() 等。
|
||||
+ 由于可能在提交时回滚，因此也不支持 XA 事务 (分布式事务) 。
|
||||
+ 所有表必须具有主键。
|
||||
+ 由于节点是对等的，所以整个集群的写吞吐量受限于性能最差的节点，如果一个节点变慢，则整个群集都会变慢。因此应该保证所有节点的硬件配置一致，并避免单个节点超负载运行。
|
||||
+ 允许的最大事务大小由 wsrep_max_ws_rows 和 wsrep_max_ws_size 参数共同定义，因此超大型事务会被拆分为一系列小型事务，如加载大数据集 LOAD DATA INFILELOAD DATA。
|
||||
+ 由于在集群级别采用乐观锁进行并发控制，所以事务在 COMMIT 阶段仍然有被中止的可能。如两个事务在不同的集群节点上提交对相同的行的写入，此时只有其中一个可以成功提交，另一个将被中止。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
虽然 PXC 集群存在以上限制，但就目前而言，它仍然是解决数据一致性和高可用性的最好方案，其搭建步骤如下：
|
||||
|
||||
## 二、集群搭建
|
||||
|
||||
为保证集群高可用，群集最少要有 3 个节点，这里以搭建一个 3 节点的集群为例，具体如下：
|
||||
|
||||
### 2.1 准备安装
|
||||
|
||||
@ -54,7 +73,7 @@ sudo yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
|
||||
sudo yum install Percona-XtraDB-Cluster-57
|
||||
```
|
||||
|
||||
安装完成后，通过以下命令启动数据库服务：
|
||||
使用以上命令安装完成后，会同时安装好 Percona Server 数据库，它基于 MySQL 社区版进行了扩展增强，并完全兼容原有版本，使用方式也完全一致，启动命令如下：
|
||||
|
||||
```shell
|
||||
sudo systemctl start mysql
|
||||
@ -141,7 +160,7 @@ wsrep_node_address=192.168.0.228
|
||||
sudo systemctl start mysql@bootstrap.service
|
||||
```
|
||||
|
||||
在将其他节点添加到群集之前，需要登录当前节点，来为 SST 创建用户并提供权限，命令如下：
|
||||
在将其他节点添加到群集之前，需要登录当前节点，来为 SST 操作创建用户并提供权限，命令如下：
|
||||
|
||||
```shell
|
||||
# 创建用户
|
||||
@ -178,4 +197,10 @@ systemctl stop mysql@bootstrap.service
|
||||
service stop mysql
|
||||
```
|
||||
|
||||
由于所有节点都是对等的，所以下线第一个节点和下线其他节点在效果上都是相同的。
|
||||
由于所有节点都是对等的，所以下线第一个节点和下线其他节点在效果上都是相同的，以上就是关于 PXC 集群搭建的全部内容。
|
||||
|
||||
|
||||
|
||||
## 参考资料
|
||||
|
||||
[Percona XtraDB Cluster 5.7 Documentation](https://www.percona.com/doc/percona-xtradb-cluster/LATEST/index.html)
|
||||
@ -45,7 +45,6 @@ InnoDB 是 MySQL 5.5 之后默认的存储引擎，它是一种兼具高可靠
|
||||
|
||||
|
||||
<div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/innodb-architecture.png"/> </div>
|
||||
|
||||
### 1.2 MyISAM
|
||||
|
||||
MyISAM 是 MySQL 5.5 之前默认的存储引擎。创建 MyISAM 表时会创建两个同名的文件：
|
||||
@ -120,19 +119,15 @@ mysql> SELECT * FROM total;
|
||||
**平衡二叉树数据结构**：
|
||||
|
||||
<div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/avl-tree.png"/> </div>
|
||||
|
||||
**红黑树数据结构**：
|
||||
|
||||
<div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/red-black-tree.png"/> </div>
|
||||
|
||||
**Btree 数据结构**：
|
||||
|
||||
<div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/btree.png"/> </div>
|
||||
|
||||
**B+ Tree 数据结构**
|
||||
|
||||
<div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/B+Trees.png"/> </div>
|
||||
|
||||
从上面的图示中我们可以看出 B+ Tree 树具有以下优点：
|
||||
|
||||
+ B+ Tree 树的所有非叶子节点 (如 003，007)，都会在叶子节点冗余一份，所有叶子节点都按照链表的方式进行组织，这样带来的好处是在范围查询中，只需要通过遍历叶子节点就可以获取到所有的索引信息。
|
||||
@ -145,11 +140,9 @@ mysql> SELECT * FROM total;
|
||||
对于 InnoDB ，因为主键索引是聚集索引，所以其叶子节点存储的就是实际的数据。而非主键索引存储则是主键的值 ：
|
||||
|
||||
<div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/mysql-innodb-索引.png"/> </div>
|
||||
|
||||
对于 MyISAM，因为主键索引是非聚集索引，所以其叶子节点存储的只是指向数据位置的指针：
|
||||
|
||||
<div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/mysql-myisam-索引.png"/> </div>
|
||||
|
||||
综上所述，B+ tree 普遍适用于范围查找，优化排序和分组等操作。B+ tree 的查找是基于字典序的，因此其适用的具体查询类型如下：
|
||||
|
||||
+ **全值匹配**：以索引为条件进行精确查找。如 `emp_no` 字段为索引，查询条件为 `emp_no = 10008`；
|
||||
@ -288,25 +281,21 @@ InnoDB 存储引擎完全支持 ACID 模型：
|
||||
一个事务的更新操作被另外一个事务的更新操作锁覆盖，从而导致数据不一致：
|
||||
|
||||
<div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/mysql-修改丢失.png"/> </div>
|
||||
|
||||
**2. 脏读**
|
||||
|
||||
在不同的事务下，一个事务读取到其他事务未提交的数据：
|
||||
|
||||
<div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/mysql-脏读.png"/> </div>
|
||||
|
||||
**3. 不可重复读**
|
||||
|
||||
在同一个事务的两次读取之间，由于其他事务对数据进行了修改，导致对同一条数据两次读到的结果不一致：
|
||||
|
||||
<div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/mysql-不可重复读.png"/> </div>
|
||||
|
||||
**4.幻读**
|
||||
|
||||
在同一个事务的两次读取之间，由于其他事务对数据进行了修改，导致第二次读取到第一次不存在数据，或第一次原本存在的数据，第二次却读取不到，就好像之前的读取是 “幻觉” 一样：
|
||||
|
||||
<div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/mysql-幻读.png"/> </div>
|
||||
|
||||
### 4.4 隔离级别
|
||||
|
||||
想要解决以上问题，可以通过设置隔离级别来实现：InnoDB 支持以下四个等级的隔离级别，默认隔离级别为可重复读：
|
||||
@ -331,7 +320,35 @@ InnoDB 存储引擎完全支持 ACID 模型：
|
||||
|
||||
## 五、数据库设计范式
|
||||
|
||||
数据库设计当中常用的三范式如下：
|
||||
|
||||
#### 第一范式：属性不可分
|
||||
|
||||
要求表中的每一列都是不可再细分的原子项。这是最低的范式要求，通常都能够被满足。
|
||||
|
||||
#### 第二范式：属性完全依赖于主键
|
||||
|
||||
要求非主键列必须完全依赖于主键列，而不能存在部分依赖。示例如下：
|
||||
|
||||
| mechanism_id （组织机构代码） | employee_id （雇员编号） | ename （雇员名称） | cname （组织机构名称） |
|
||||
| ----------------------------- | ------------------------ | ------------------ | ---------------------- |
|
||||
| 28193182 | 10001 | heibaiying | XXXX公司 |
|
||||
|
||||
以上是一张全市在职人员统计表，主键为：机构编码 + 雇员编号，这里的雇员名称完全依赖于此联合主键，但机构名称就只依赖于机构代码，这就出现了部分依赖，违背了第二范式。此时最好的解决方式就是建立一张组织机构与组织名称的字典表。
|
||||
|
||||
#### 第三范式：避免传递依赖
|
||||
|
||||
非主键列不能依赖于其他非主键列，如果其他非主键列又依赖于主键列，此时就出现了传递依赖。示例如下：
|
||||
|
||||
| employee_id （雇员编号） | ename （雇员名称） | dept_no (部门编号) | dname（部门名称） |
|
||||
| ------------------------ | ------------------ | ------------------ | ----------------- |
|
||||
| 10001 | heibaiying | 06 | 开发部 |
|
||||
|
||||
这里还是一张雇员表，雇员名称和所属的部门编号都依赖于主键 employee_id ，但部门名称却依赖于部门编号，此时就出现了非主键列依赖于其他非主键列，这就违背的第三范式。此时最好的解决方式就是建立一张部门表用于维护部门相关的信息。
|
||||
|
||||
#### 反范式设计
|
||||
|
||||
从上面的例子中我们也可以看出，想要完全遵循三范式设计，可能需要额外增加很多表来进行维护。所以在日常开发中，基于其他因素的综合考量，可能并不会完全遵循范式设计，甚至可能违反范式设计，这就是反范式设计。
|
||||
|
||||
|
||||
|
||||
|
||||
@ -63,7 +63,6 @@ MySQL 的复制原理如下图所示：
|
||||
<div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/mysql-replication.jpg"/> </div>
|
||||
|
||||
|
||||
|
||||
### 2.2 配置步骤
|
||||
|
||||
首先主节点需要开启二进制日志，并且在同一个复制环境下，主备节点的 server-id 需要不一样：
|
||||
@ -357,7 +356,7 @@ MMM (Master-Master replication manager for MySQL) 是由 Perl 语言开发的一
|
||||
|
||||
除了管理双主节点，MMM 也负责管理所有 Slave节点，在出现宕机、复制延迟或复制错误，MMM 会移除该节点的 VIP，直至节点恢复正常。MMM 高可用的架构示例图如下：
|
||||
|
||||
|
||||
<div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/mysql-MMA架构.jpg"/> </div>
|
||||
|
||||
MMM 架构的缺点在于虽然其能实现自动切换，但却不会主动补齐丢失的数据，所以会存在数据不一致性的风险。另外 MMM 的发布时间比较早，所以其也不支持 MySQL 最新的基于 GTID 的复制，如果你使用的是基于 GTID 的复制，则只能采用 MHA。
|
||||
|
||||
@ -365,7 +364,7 @@ MMM 架构的缺点在于虽然其能实现自动切换，但却不会主动补
|
||||
|
||||
MHA (Master High Availability) 是由 Perl 实现的一款高可用程序，相对于 MMM ，它能尽量避免数据不一致的问题。它监控的是一主多从的复制架构，架构如下图所示：
|
||||
|
||||
|
||||
<div align="center"> <img src="https://github.com/heibaiying/Full-Stack-Notes/blob/master/pictures/mysql-MHA架构.jpg"/> </div>
|
||||
|
||||
在 Master 节点宕机后，其处理流程如下：
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user