持续创作,加速成长!这是我参与「掘金日新计划 · 6 月更文挑战」的第10天,点击查看活动详情
你好,我是悟空。
业界流传一句话:没有做过运维的程序员不是好架构师。不知是真是假。
本篇内容如下:
前言
对于 MySQL 数据库作为各个业务系统的存储介质,在系统中承担着非常重要的职责,如果数据库崩了,那么对于读和写数据库的操作都会受到影响。如果不能迅速恢复,对业务的影响是非常大的。之前 B 站不是出过一次事故么,2 小时才恢复过来,详细可以看之前写的文章。B 站崩了,总结下「高可用」和「异地多活」
上次折腾完 ELK 日志检索平台后,开发环境可以正常查询日志了。最近在做系统高可用相关的工作,这次我来分享下 MySQL 双主 + Keepalived 的高可用落地和踩坑之路。
主主复制的原理
对于 MySQL 的主主架构,其实原理就是两台服务器互为主从,双向复制。而复制的原理如下:
主从复制主要有以下流程:
- 主库将数据的改变记录到 binlog 中;
- 从库会在一定时间间隔内对master 的 binlog 进行检查,如果发生改变,则开始一个 I/O Thread 请求读取 master 中 binlog ;
- 同时主库为每个 I/O 线程启动一个 dump 线程,用于向其发送二进制事件,并保存至从节点本地的中继日志中,从库将启动 SQL 线程从中继日志中读取二进制日志,在本地重放,使得其数据和主节点的保持一致,最后 I/O Thread 和 SQL Thread 将进入睡眠状态,等待下一次被唤醒;
大白话就是:
从库会生成两个线程,一个 I/O 线程,一个 SQL 线程;
I/O 线程会去请求主库的 binlog,并将得到的 binlog 写到本地的 relay-log (中继日志)文件中;
主库会生成一个 dump 线程,用来给从库 I/O 线程传 binlog;
SQL 线程,会读取 relay log 文件中的日志,并解析成 SQL 语句逐一执行;
接下来我们先把 MySQL 的基础环境在两台 Ubuntu 服务器上搭建好,后续操作都是基于这个来做的。
接下来我们配置 MySQL 的主从架构,需要注意的是后续搭建的主主架构是基于主从架构来的,区别就是修改了一部分配置。