mysql分布式-复制篇

作用

对数据备份，实现存储高可用

通过读写分离，提高吞吐量，实现高性能

---

原理

原理

Mysql的复制 是⼀个异步的复制过程

过程本质为 Slave 从 Master 端获取 Binary Log, 然后再在⾃⼰身上完全顺序的执⾏⽇志中所记录的各种操作

MySQL 复制的基本过程如下:

1，Slave 上⾯的 IO 线程连接上 Master， 并请求从指定⽇志⽂件的指定位置之后的⽇ 志内容。

2，Master 接收到来⾃ Slave 的 IO 线程的请求后， 通过负责复制的IO线程 根据请求信息读取⽇志信息， 返回给 Slave 端的 IO 线程。

3，Slave 的 IO 线程接收到信息后， 将接收到的⽇ 志内容依次写⼊到 Slave 端的 Relay Log⽂件。

4，Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后， 会⻢上解析该⽂件中的内容, 并在⾃身执⾏这些 原始SQL语句。

---

常用架构

1，主从架构

    性能：

            ⼀主多从, 读写分离, 提⾼吞吐量

    可用性：

            主库单点, ⼀旦挂了, ⽆法写⼊

            从库⾼可⽤

主从架构图

2，主备架构

    性能：

            单库读写, 性能⼀般

    可用性：

            ⾼可⽤, ⼀旦主库挂了, 就启⽤备库

主备架构图

问题：既然主备互为备份，为何不采用双主方案，提供两台主进行负载均衡？

答案：原因是为了避免数据的冲突， 防⽌造成数据的不⼀致性。 虽然在两边执⾏的修改有先后顺序， 但由于 Replication 是异步的实现机制， 同样可能会导致晚做的修改被早做的修改所覆盖

例子

可以看到不仅B库数据错误, 且A&B库数据不⼀致

主备架构搭建除了配置双主同步, 还需要搭配第三⽅故障转移/⾼可⽤⽅案

3，高可用复合架构

    性能：

            读写分离, 提⾼吞吐量

    可用性：

            ⾼可⽤, ⼀旦主库挂了, 就启⽤备库

            A库宕机走B库，B库宕机走A库

高可用复合架构图

---

读写分离

flask(SQLAlchemy)的读写分离：

    SQLAlchemy进行读写分离的基本思路

        1，实现⾃定义的 session 类, 继承 SignallingSession 类

            --重写 get_bind ⽅法, 根据读写需求选择对应的数据库地址

        2，实现⾃定义的 SQLAlchemy 类, 继承 SQLAlchemy 类

            --重写 create_session ⽅法, 在内部使⽤⾃定义的 Session 类

SQLAlchemy的读写分离代码

django的读写分离：

django进行读写分离的基本思路

1，在项目的app文件中创建db_route.py文件，直接在文件里定义一个数据库路由类，用以区分读写操作。

2，settings.py中把从机加入到数据库的配置文件中，写个路由配置

django的读写分离代码

下面还有mysql的分片，下期分享，88