墨斗鱼业务MYSQL架构-从无到有

Posted 2020-09-03

项目描述 

    采用mysql 复制的方式 作为项目的数据库底层架构 写操作在MASTER 读在SLAVE 上

主库采用

MYSQL5.6版本

从库采用 

MYSQL5.7版本 #为了测试MYSQL5.7的版本和旧版本的兼容性

INNODB存储引擎 每张表有自增id做主键，RR隔离级别

1. 配置环境描述

    1.1 binlog 格式的选择

        常用binlog格式 有 STATEMENT,ROW,MIXED

    采用ROW格式作为binlog日志格式

    ROW格式优点 特殊函数能有效复制 安全 表有自增id做主键 复制速度会更快

    如果选择SRB和MIX复制 可能特殊的函数不能有效复制例如 uuid now 等

    1.2从开启了 read_onle和super_read_onle 避免从写入

        read_onle=on && super_read_onle=on #这样任何账户都不能写入

    1.3采用了GTID复制模式

         GTID简介

       每一个事务都有一个唯一的编号

            uuid:n uuid是MYSQL唯一标识符 n是事务id号    

            一个事务对应一个唯一的ID,一个GTID在一个服务器只执行一次

        gtid serverid:事务id 每个事务id的编号是唯一的 不能重复执行 

        MYSQL5.6.2支持 MYSQL5.6.10完善

      GTID限制

        不支持非事务引擎（从库报错 stop slave; start slave; 忽略）

        不支持create table ....select语句复制（主库直接报错）

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

        在一个复制组中 必须要求统一开启GTID或者关闭GTID

        开启GTID需要重启（5.7不需要）

        开启GTID后，就不在使用原来的传统复制方式

        对于create tmporary table 和drop temporary table 语句不支持

        不支持 sql_slave_skip_counter

        个人理解： 

            GTID 有利于主从维护 主从复制 主从一致性的校验 主从切换等 

    双一 保证数据的一致性 MASTER innodb_flush_log_at_trx_commit=1 sync_binlog=1

        当时的压力测试满足了当前业务 主从都开启了双一

 配置了 域名指定了master 和slave的主机 

         这样应用程序就不用去修改了 用Ansible 自动同步host文件

缺点：

    1.主从故障手动切换 监控要做好 要第一时间去做切换

    2.数据一致性难以保证（1）

中期环境改进

keepalived-1.2.13 

MYSQL5.7 MASTER

MYSQL5.7 MASTER

2.配置描述

    利用keepalived做双主结构 MYSQL也做双主 互为主从关系 

        auto_increment_increment=2#自增

        auto_increment_offset=1/2#起始步长

     keepalived:MYSQL 不是在同一个交换机上  就在检测脚本里面写ping 网关 如果不通返回非0，为了防止脑裂

    在MASTER和SLAVE 开启 master_info_repository=table relay_log_info_repository=tblae 

主从记录 写到table里面 不是写入到系统的文件里面

    开启了relay_log_recovery 为了防止 relay在执行过程中 SLAVE突然关闭 或者relay log 损坏

缺点：

    1.会造成更新丢失问题 这时候就很难判断以主库数据为准还是从库数据为准

        二台机器同时 update 不会造成堵塞 也不会造成锁 根据主键更新 都会写入binlog 然后传递对方的relay log 并应用 所以造成更新丢失。因为 主从复制 根据主键更新  不会校队其他数据 。如果没有主键 根据二级索引进行更新 利用第一个最长的索引匹配主键， 如果都没有 全表扫描更新。

双主结构 PXC结构 MGR结构 都会造成这个问题 解决办法 单台机器进行update。insert或者delete 可以负载分发

    2.如果MASTER传输 binlog的时候 没有安全的传输到SLAVE  也会造成数据不一致

3.后期环境改进

proxysql-1.3.4 读写分离

keepalived-1.2.13 

MYSQL5.7 MASTER

MYSQL5.7 MASTER

MYSQL5.7 SLAVE.....多个

    配置描述

    1.解决数据一致性难以保证（1） 的问题 

        双1解决了 客户提交后 数据库成功执行后 写到redo log和binlog 也就是双阶段提交

        采用5.7增强半同步 解决了 MASTER的binlog传输到SLAVE上 才会提交 返回客户端

        双table 避免文件没有及时刷新 MASTER的file和pos信息 造成日志点的丢失

        开启了relay_log_recovery 为了防止 relay在执行过程中 SLAVE突然关闭 或者relay log 损坏，如果发现没执行完毕 异常关闭 就重新执行relay log

        row格式 gtid 复制格式

    2.用proxysql 做读写分离 MYSQL5.7 MASTER 进行写的操作 MASTER2 和slave做读操作

    3.MASTER1和MASTER 双主 做了增强半同步复制

    4.采用了MYSQL5.7的并行复制 是组提交级别 非5.6 库提交级别 真正的并行复制

缺点

    1.正在解决 如果节点 挂了后修复 重新添加到proxysql信息 

    打算用python实现自动化添加节点 更改节点信息

本文出自 “linux” 博客，谢绝转载！