实战 MySQL 高可用架构(二)

·  阅读 57

持续创作,加速成长!这是我参与「掘金日新计划 · 6 月更文挑战」的第10天,点击查看活动详情

你好,我是悟空。

业界流传一句话:没有做过运维的程序员不是好架构师。不知是真是假。

本篇内容如下:

前言

对于 MySQL 数据库作为各个业务系统的存储介质,在系统中承担着非常重要的职责,如果数据库崩了,那么对于读和写数据库的操作都会受到影响。如果不能迅速恢复,对业务的影响是非常大的。之前 B 站不是出过一次事故么,2 小时才恢复过来,详细可以看之前写的文章。B 站崩了,总结下「高可用」和「异地多活」

上次折腾完 ELK 日志检索平台后,开发环境可以正常查询日志了。最近在做系统高可用相关的工作,这次我来分享下 MySQL 双主 + Keepalived 的高可用落地和踩坑之路。

主主复制的原理

对于 MySQL 的主主架构,其实原理就是两台服务器互为主从,双向复制。而复制的原理如下:

主从复制主要有以下流程:

  1. 主库将数据的改变记录到 binlog 中;
  2. 从库会在一定时间间隔内对master 的 binlog 进行检查,如果发生改变,则开始一个 I/O Thread 请求读取 master 中 binlog ;
  3. 同时主库为每个 I/O 线程启动一个 dump 线程,用于向其发送二进制事件,并保存至从节点本地的中继日志中,从库将启动 SQL 线程从中继日志中读取二进制日志,在本地重放,使得其数据和主节点的保持一致,最后 I/O Thread 和 SQL Thread 将进入睡眠状态,等待下一次被唤醒;

image.png

大白话就是:

从库会生成两个线程,一个 I/O 线程,一个 SQL 线程;

I/O 线程会去请求主库的 binlog,并将得到的 binlog 写到本地的 relay-log (中继日志)文件中;

主库会生成一个 dump 线程,用来给从库 I/O 线程传 binlog;

SQL 线程,会读取 relay log 文件中的日志,并解析成 SQL 语句逐一执行;

接下来我们先把 MySQL 的基础环境在两台 Ubuntu 服务器上搭建好,后续操作都是基于这个来做的。

接下来我们配置 MySQL 的主从架构,需要注意的是后续搭建的主主架构是基于主从架构来的,区别就是修改了一部分配置。

分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改