MySQL 集群：奏响数据交响曲的强大乐章

本文主要是介绍MySQL 集群：奏响数据交响曲的强大乐章，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

一、Mysql 在服务器中的部署方法

下载并解压源码包

[root@mysql ~]# tar -zxf mysql-boost-5.7.44.tar.gz

源码编译安装mysql

 [root@mysql mysql-5.7.44]# cmake \
> -DCMAKE_INSTALL_PREFIX=/usr/local/mysql \                                  #指定安装路径
> -DMYSQL_DATADIR=/data/mysql \                                                       #指定数据目录
> -DMYSQL_UNIX_ADDR=/data/mysql/mysql.sock \                              #指定套接字文件
> -DWITH_INNOBASE_STORAGE_ENGINE=1 \    #指定启用INNODB存储引擎，默认用myisam

> -DWITH_EXTRA_CHARSETS=all \                                                     #扩展字符集
> -DDEFAULT_CHARSET=utf8mb4 \                                                     #指定默认字符集
> -DDEFAULT_COLLATION=utf8mb4_unicode_ci \                              #指定默认校验字符集
> -DWITH_BOOST=/root/mysql-5.7.44/boost/boost_1_59_0/                #指定c++库依赖

 注意不要有报错

 [root@mysql mysql-5.7.44]# make -j4              #-j2 表示有几个核心就跑几个进程

 然后make install

[root@mysql mysql-5.7.44]# make install
注意过程不能有报错

 MySQL安装及初始化

 生成启动脚本

 [root@mysql ~]# cd /usr/local/mysql/support-files/

 [root@mysql support-files]# cp mysql.server /etc/init.d/mysqld

 修改环境变量

生成数据目录  

修改配置文件  

[root@mysql ~]# cat /etc/my.cnf
[mysqld]
datadir=/data/mysql                                                         #指定数据目录
socket=/data/mysql/mysql.sock                                        #指定套接字
symbolic-links=0                                               #数据只能存放到数据目录中，禁止链接到数据目录

数据库初始化建立mysql基本数据  

数据库安全初始化  

 [root@mysql ~]# mysql_secure_installation

二、MySQL的主从复制

MySQL 主从复制是一种常用的数据库架构技术，它可以实现数据的备份、负载均衡和高可用性。在 MySQL 主从复制中，一个主数据库（Master）将数据变更同步到多个从数据库（Slave），从而实现数据的冗余和分布式处理。

主从复制的原理

1. 主数据库将数据变更记录到二进制日志（Binary Log）中。
2. 从数据库连接到主数据库，并请求读取二进制日志。
3. 主数据库将二进制日志发送给从数据库。
4. 从数据库将接收到的二进制日志应用到自己的数据库中，从而实现数据的同步。

主从复制的配置步骤

1. 配置主数据库

   • 开启二进制日志功能。
   • 设置唯一的服务器 ID。
   • 创建用于从数据库连接的用户，并授予复制权限。

2. 配置从数据库

   • 设置唯一的服务器 ID。
   • 指定主数据库的连接信息，包括主机名、端口号、用户名和密码。
   • 启动从数据库的复制线程。

主从复制的应用场景

1. 数据备份

   • 从数据库可以作为主数据库的备份，当主数据库出现故障时，可以快速切换到从数据库，保证数据的可用性。

2. 负载均衡

   • 可以将读操作分发到多个从数据库上，从而减轻主数据库的负载，提高系统的性能。

3. 高可用性

   • 通过配置多个从数据库，可以实现主数据库的故障转移，提高系统的可用性。

master

slave

重启数据库

master

slave

 master开启二进制日志

重启数据库

 进入数据库配置用户权限

master 

mysql> create user repl@'%' identified by '123456';     #生成专门用来做复制的用户，此用户是用于slave端做认证用

mysql> grant replication slave on *.* to repl@'%';         #对这个用户进行授权

 mysql> show master status;                                        #查看master的状态

 slave

mysql> change master to master_host='172.25.254.128',master_user='repl',master_password='123456',master_log_file='mysql-bin.000001',master_log_pos=595;

mysql> start slave;

mysql> show slave status\G;

 在slave阶段中默认情况下是开启了写功能的，但是建议关闭slave节点的写功能来保证数据一致性

测试

master

 slave

当有数据时添加mysql-node2  

 添加一个新节点mysql-node2        安装数据库并进行相关的配置

生产环境中备份时需要锁表，保证备份前后的数据一致

mysql> FLUSH TABLES WITH READ LOCK;

备份后再解锁

mysql> UNLOCK TABLES;

mysqldump 命令备份的数据文件，在还原时先 DROP TABLE ，需要合并数据时需要删除此语句

从master节点备份数据

 [root@mysql ~]#  mysqldump -uroot -p tc > tc.sql

将备份的数据传输到新的节点上

[root@mysql ~]#  scp tc.sql root@172.25.254.153:/mnt/

利用master节点中备份出来的tc.sql在mysql-node2中拉平数据

[root@mysql-node2 ~]# mysql -uroot -p123456 -e"create database tc;"

[root@mysql-node2 mnt]# mysql -uroot -p123456 tc < tc.sql

mysql> change master to master_host='172.25.254.128',master_user='repl',master_password='123456',master_log_file='mysql-bin.000001',master_log_pos=1499;

 master插入数据

mysql-node2（原始数据在，新插入的数据也在）

延迟复制

在slave端

mysql> stop slave sql_thread;

mysql> change master to master_delay=60;

mysql> start slave sql_thread;

mysql> show slave status\G;

测试一下

mysql-node2（等一分钟后）

慢查询日志

开启慢查询日志

mysql> set global slow_query_log=on;

MySQL主从复制缺陷

MySQL 主从复制架构存在以下一些缺陷：

数据一致性问题

1. 主从延迟

   • 在主库写入数据后，从库可能需要一定时间才能同步完数据。如果应用在此时读取从库，可能会得到旧的数据，导致数据不一致。例如，在一些对数据实时性要求很高的业务场景中，如金融交易系统，这种延迟可能会带来严重的问题。
   • 造成主从延迟的原因有很多，比如从库的硬件性能比主库差、网络延迟高、主库写入压力大等。

2. 复制中断后的不一致

   • 如果主从复制过程中出现网络故障、从库宕机等情况，导致复制中断，在恢复复制后，可能会出现数据不一致的情况。此时需要进行数据修复，这是一个复杂且可能存在风险的过程。

故障切换问题

1. 自动切换的复杂性

   • 虽然可以通过一些工具实现主从复制架构下的自动故障切换，但这个过程并不简单。需要考虑如何检测主库故障、如何选择新的主库、如何保证切换过程中的数据一致性等问题。
   • 例如，在一些高并发的系统中，故障切换可能会导致短暂的服务中断，影响用户体验。

2. 脑裂问题

   • 在某些情况下，可能会出现两个节点都认为自己是主库的情况，即脑裂。这会导致数据的混乱和不一致，修复起来也非常困难。

性能瓶颈

1. 单主库的写入瓶颈

   • 所有的写入操作都必须在主库上进行，当写入压力很大时，主库可能会成为性能瓶颈。即使有多个从库分担读负载，但主库的写入性能仍然可能无法满足业务需求。
   • 例如，在一些大型电商平台的促销活动期间，数据库的写入量会大幅增加，主库可能无法承受这么大的压力。

2. 从库的复制压力

   • 从库在进行数据复制时也会消耗一定的系统资源，如果从库数量过多或者主库写入量过大，从库可能会因为复制压力过大而影响其读性能。

三、MySQL的并行复制 

在slaves中设定

四、MySQL半同步模式

MySQL 的半同步复制模式是在传统异步复制和全同步复制之间的一种折衷方案，其主要目的是在一定程度上保证数据的强一致性，同时尽量减少对性能的影响。以下是其原理

基本概念

在传统的异步复制中，主库将事务写入 binlog 日志后，就可以向客户端返回成功响应，而不必等待从库接收并应用这些日志。这可能导致在主库发生故障切换到从库时，从库丢失一些尚未复制的事务。

全同步复制则要求主库在将事务写入 binlog 日志后，必须等待所有从库都接收并应用完这些日志后，才能向客户端返回成功响应。这种方式虽然能保证数据的强一致性，但会极大地影响主库的性能，特别是在从库数量较多或者网络延迟较高的情况下。

半同步复制则介于两者之间，主库在将事务写入 binlog 日志后，至少等待一个从库接收并写入 relay log（中继日志）后，才向客户端返回成功响应。

工作流程

1. 主库执行事务

   • 当客户端向主库发起一个事务请求时，主库开始执行这个事务，并将事务的操作记录到 binlog 日志中。

2. 事务提交

   • 主库在事务执行完成后，准备提交事务。此时，主库会检查是否有至少一个从库已经接收到了该事务的 binlog 日志并写入到 relay log 中。如果有，主库则认为该事务已经成功复制到至少一个从库，可以安全地提交事务，并向客户端返回成功响应。
   • 如果没有从库确认接收到了该事务的 binlog 日志，主库会等待一段时间，等待从库的响应。如果在等待时间内有从库响应，主库则提交事务并返回成功响应；如果等待超时，主库会切换回异步复制模式，提交事务并返回成功响应，但会记录一条警告信息。

3. 从库接收并应用事务

   • 从库通过 I/O 线程从主库读取 binlog 日志，并将其写入到本地的 relay log 中。然后，从库的 SQL 线程会读取 relay log 中的事务，并在从库上执行这些事务，从而实现数据的同步。

优点

1. 提高数据一致性

   • 相比异步复制，半同步复制能够在一定程度上保证主库和从库之间的数据一致性。当主库发生故障切换到从库时，丢失数据的可能性大大降低。

2. 减少数据丢失风险

   • 在主库出现故障时，如果采用异步复制，可能会有一些事务还未复制到从库就丢失了。而半同步复制则可以减少这种风险，因为至少有一个从库已经接收到了事务的 binlog 日志。

缺点

1. 性能影响

   • 由于主库需要等待从库的响应，所以半同步复制会在一定程度上影响主库的性能，特别是在网络延迟较高或者从库性能较差的情况下。

2. 复杂性增加

   • 半同步复制的配置和管理相对复杂，需要考虑网络延迟、从库数量、等待超时时间等因素。如果配置不当，可能会导致性能下降或者数据不一致的问题。

 gtid模式

当为启用gtid时我们要考虑的问题

设置gtid

在master端和slave端开启gtid模式

master

slave

 查看日志

 停止slave端

开启slave端的gtid

master

启用半同步模式

在master端配置启用半同步模式

安装半同步插件  

查看插件情况

打开半同步功能 （默认已经打开了）

如果没打开，使用一下命令

在slave端开启半同步功能

 安装半同步插件

重启IO线程，半同步才能生效

 测试一下

 模拟故障

 在slave端

 slave开启IO线程

 数据成功写入

五、MySQL高可用之组复制 (MGR)

组复制流程

组复制单主和多主模式

single-primary mode(单写或单主模式)

multi-primary mode(多写或多主模式)

实现mysql组复制

 配置sql

注意这块的MEMBER_HOST下面是主机名，所以我们一定要做解析（三个节点都需要做解析）

复制配置文件到myql-node1和mysql-node2并修改

对myql-node1和mysql-node2的数据库进行初始化

 配置sql

测试

 

在myql-node1和mysql-node2上插入数据

假如myql-node1下线了

myql-node1上线是不会自动加入组复制的

要想加入，需要执行以下命令

 mysql> START GROUP_REPLICATION;

六、MySQL-router（mysql路由）

MySQL-router概述

主要功能

1. 路由功能

   • MySQL Router 可以根据配置将客户端的连接请求路由到合适的 MySQL 服务器实例上。例如，在主从复制架构中，它可以将读请求路由到从库，将写请求路由到主库，实现读写分离，提高数据库的性能和可用性。
   • 它通过解析 MySQL 协议，能够在不修改客户端应用程序的情况下实现透明的路由。

2. 负载均衡

   • 在多个 MySQL 服务器实例组成的集群中，MySQL Router 可以实现负载均衡，将客户端的连接均匀地分配到不同的服务器上，避免单个服务器负载过高。
   • 支持多种负载均衡算法，如轮询、随机等，可以根据实际需求进行选择。

3. 高可用性

   • 当 MySQL 服务器实例出现故障时，MySQL Router 可以自动检测到故障，并将连接请求路由到其他可用的服务器上，实现自动故障转移，提高系统的可用性。
   • 它通过定期检测服务器的健康状态，确保只将连接请求路由到正常运行的服务器上。

工作原理

1. 配置文件

   • MySQL Router 通过读取配置文件来了解 MySQL 服务器实例的拓扑结构和路由规则。配置文件中可以指定主库、从库的地址，以及路由策略等信息。
   • 例如，可以在配置文件中指定多个从库，并设置负载均衡算法为轮询，这样 MySQL Router 就会将读请求依次分配到不同的从库上。

2. 连接管理

   • 当客户端连接到 MySQL Router 时，Router 会根据配置文件中的路由规则将连接请求转发到相应的 MySQL 服务器实例上。
   • 如果连接的服务器出现故障，Router 会自动切换到其他可用的服务器上，保持客户端连接的连续性。

3. 健康检测

   • MySQL Router 会定期对配置文件中指定的 MySQL 服务器实例进行健康检测，以确定它们的可用性。
   • 如果检测到服务器故障，Router 会更新内部的路由表，将连接请求路由到其他正常的服务器上。

优点

1. 轻量级和易于部署

   • MySQL Router 是一个轻量级的中间件，安装和配置相对简单。它可以快速部署在现有的 MySQL 架构中，无需对客户端应用程序进行大规模的修改。

2. 透明的路由和负载均衡

   • 对于客户端应用程序来说，MySQL Router 实现了透明的路由和负载均衡，客户端无需关心数据存储在哪个服务器上，只需要连接到 Router 即可。

3. 高可用性

   • 通过自动故障转移和健康检测功能，MySQL Router 提高了 MySQL 数据库的高可用性，确保系统在服务器故障时能够继续提供服务。

缺点

1. 单点故障

   • 如果 MySQL Router 本身出现故障，客户端将无法连接到 MySQL 服务器。为了解决这个问题，可以部署多个 Router 实例，并使用负载均衡器来实现高可用性。

2. 性能开销

   • 由于 MySQL Router 需要解析 MySQL 协议并进行路由和负载均衡，它会引入一定的性能开销。在高并发的环境下，可能会对系统性能产生一定的影响。

3. 配置复杂性

   • 虽然 MySQL Router 的配置相对简单，但对于复杂的数据库架构，配置文件可能会变得比较复杂，需要仔细规划和管理。

 Mysql route的部署方式

 上传需要的rpm包

安装mysql-router

master

slave

配置mysql-router

[root@mysql ~]# vim /etc/mysqlrouter/mysqlrouter.conf 

启动服务并查看端口

建立测试用户

注意：mysql router 并不能限制数据库的读写，访问分流

上面演示的是轮询，还可设置为最先响应，具体配置如下

[routing:rw]

bind_address = 0.0.0.0

bind_port = 7002

destinations = 172.25.254.163:3306,172.25.254.152:3306,172.25.254.128:3306

routing_strategy = first-available 

七、MySQL高可用集群MHA 

MHA概述

MySQL 高可用集群 MHA（Master High Availability）是一套优秀的 MySQL 主从复制环境下的高可用解决方案。

主要功能

1. 自动故障转移

   • MHA 可以自动检测 MySQL 主库的故障，并在短时间内实现故障转移，将从库提升为主库，确保数据库服务的连续性。
   • 例如，当主库发生硬件故障或软件错误导致不可用时，MHA 能够快速识别并选择一个最佳的从库进行切换，最大限度地减少服务中断时间。

2. 数据一致性保证

   • 在进行故障转移时，MHA 会确保数据的一致性。它会通过分析从库的中继日志（relay log），找到与主库最接近的同步点，并在新主库上应用剩余的事务，以保证数据的完整性。
   • 这样可以避免在故障转移后出现数据丢失或不一致的情况。

3. 主库在线切换

   • MHA 支持在线主库切换，即可以在不影响业务的情况下，将主库切换到另一个节点。这对于计划内的维护操作或性能优化非常有用。
   • 例如，可以在业务低峰期进行主库切换，以进行硬件升级或软件更新。

4. 监控和管理

   • MHA 提供了一套监控工具，可以实时监控 MySQL 主从复制环境的状态，包括主库和从库的健康状况、复制延迟等。
   • 同时，MHA 还提供了一些管理命令，方便管理员进行故障排除和维护操作。

MHA 的组成

工作原理

1. 节点角色

   • MHA 集群由一个管理节点（Manager Node）和多个数据库节点（Database Node）组成。管理节点负责监控和管理整个集群，数据库节点则是实际的 MySQL 服务器实例。
   • 在主从复制环境中，通常有一个主库和多个从库。管理节点会定期检查主库的健康状况，并与从库进行通信，以获取复制状态信息。

2. 故障检测

   • MHA 通过多种方式检测主库的故障，包括网络连接检测、MySQL 进程状态检测、复制状态检测等。
   • 如果管理节点发现主库不可用，它会立即启动故障转移流程。

3. 故障转移流程

   • 首先，管理节点会选择一个最佳的从库作为新的主库。选择的标准通常包括从库的复制延迟、数据完整性、服务器性能等因素。
   • 然后，管理节点会在新主库上应用剩余的事务，以保证数据的一致性。同时，它会将其他从库重新指向新主库，并启动复制。
   • 最后，管理节点会通知客户端应用程序新主库的地址，以便客户端能够继续连接到数据库服务。

优点

1. 高可用性

   • MHA 能够在主库故障时快速实现故障转移，确保数据库服务的连续性，提高了系统的可用性。

2. 数据一致性

   • 通过严格的数据一致性保证机制，MHA 可以避免在故障转移后出现数据丢失或不一致的情况。

3. 易于部署和管理

   • MHA 的安装和配置相对简单，管理员可以通过命令行工具或图形界面进行管理和监控。

4. 支持多种存储引擎

   • MHA 支持 MySQL 多种存储引擎，包括 InnoDB、MyISAM 等，可以满足不同业务场景的需求。

缺点

1. 依赖于外部工具

   • MHA 需要依赖一些外部工具，如 SSH、Perl 等。这可能会增加部署和维护的复杂性。

2. 性能开销

   • MHA 在进行故障检测和故障转移时会消耗一定的系统资源，可能会对数据库性能产生一定的影响。

3. 配置复杂性

   • 对于复杂的数据库架构，MHA 的配置可能会比较复杂，需要仔细规划和调整参数。

故障切换备选主库的算法

MHA部署实施

新增一个节点作为mysql-mha

 上传需要的安装包

解压缩

做解析

做免密认证

搭建一主两从架构

 

修改两从的配置文件

 对数据库进行初始化

启动mysql并进入数据库修改密码

master

slave

安装MHA所需要的软件

[root@mysql-mha MHA-7]# yum install *.rpm -y

 注意把mha4mysql-node-0.58-0.el7.centos.noarch.rpm拷贝给master和slave节点

安装（master和slave都需要安装）

1.Manager 工具包主要包括以下几个工具：

masterha_check_ssh

# 检查 MHA 的 SSH 配置状况

masterha_check_repl

# 检查 MySQL 复制状况

masterha_manger

# 启动 MHA

masterha_check_status

# 检测当前 MHA 运行状态

masterha_master_monitor # 检测 master 是否宕机

masterha_master_switch # 控制故障转移（自动或者手动）

masterha_conf_host # 添加或删除配置的 server 信息

2.Node 工具包

（通常由 masterHA 主机直接调用，无需人为执行）

save_binary_logs # 保存和复制 master 的二进制日志

apply_diff_relay_logs # 识别差异的中继日志事件并将其差异的事件应用于其他的 slave

filter_mysqlbinlog # 去除不必要的 ROLLBACK 事件（ MHA 已不再使用这个工具）

purge_relay_logs # 清除中继日志（不会阻塞 SQL 线程）

配置MHA 的管理环境

生成配置目录和配置文件

[root@mysql-mha MHA-7]# masterha_manager --help
Usage:
    masterha_manager --global_conf=/etc/masterha_default.cnf   #全局配置文件，记录公共设定

    --conf=/usr/local/masterha/conf/app1.cnf       #不同管理配置文件，记录各自配置

    See online reference
    (http://code.google.com/p/mysql-master-ha/wiki/masterha_manager) for
    details.
 

在master节点上，创建用户并赋予权限，因为连接数据库时使用的是root用户，是不被允许远程连接的

编辑配置文件 

[server default]
user=root                                                #mysql管理员用户，因为需要做自动化配置
password=123456                                 #mysql密码
ssh_user=root                                        #ssh远程登陆用户
master_binlog_dir= /data/mysql                #二进制日志目录
remote_workdir=/tmp                                #远程工作目录
secondary_check_script= masterha_secondary_check -s 172.25.254.128 -s 172.25.254.155                #此参数使为了提供冗余检测，方式是mha主机网络自身的问题无法连接数据库节点，应为集群之外的主机
ping_interval=3                                #每隔3秒检测一次
# master_ip_failover_script= /script/masterha/master_ip_failover        #发生故障后调用的脚本，用来迁移vip
# shutdown_script= /script/masterha/power_manager        #电源管理脚本
# report_script= /script/masterha/send_report        #当发生故障后用此脚本发邮件或者告警通知
# master_ip_online_change_script= /script/masterha/master_ip_online_change        #在线切换时调用的vip迁移脚本，手动
[server default]
manager_workdir=/etc/masterha                #mha工作目录
manager_log=/etc/masterha/manager.log           #mha日志     

[server1]
hostname=172.25.254.128
candidate_master=1                #可能作为master的主机
check_repl_delay=0        

## 默认情况下如果一个 slave 落后 master 100M 的 relay logs 的话

#MHA 将不会选择该 slave 作为一个新的 master

# 因为对于这个 slave 的恢复需要花费很长时间

# 通过设置 check_repl_delay=0

#MHA 触发切换在选择一个新的 master 的时候将会忽略复制延时

# 这个参数对于设置了 candidate_master=1 的主机非常有用

# 因为这个候选主在切换的过程中一定是新的 master

[server2]
hostname=172.25.254.152
candidate_master=1                #可能作为master的主机
check_repl_delay=0

[server3]
hostname=172.25.254.153
no_master=1                        #不会作为master的主机
check_repl_delay=0

 mha主机和其他主机配置免密

master未出现故障手动切换

在master数据节点还在正常工作情况下

[root@mysql-mha ~]# masterha_master_switch \
> --conf=/etc/masterha/app1.cnf \        #指定配置文件
> --master_state=alive \                        #指定master节点状态
> --new_master_host=172.25.254.152 \                        #指定新master节点
> --new_master_port=3306 \                                #执行新master节点端口
> --orig_master_is_new_slave \                        #原始master会变成新的slave
> --running_updates_limit=10000                        #切换的超时时间

检测一下（172.25.254.152成为master）

再切换回来

测试一下

master故障手动切换

 

[root@mysql-mha ~]# masterha_master_switch  --master_state=dead --conf=/etc/masterha/app1.cnf --dead_master_host=172.25.254.128 --dead_master_port=3306 --new_master_host=172.25.254.152 --new_master_port=3306 --ignore_last_failover

--ignore_last_failover 表示忽略在 /etc/masterha/ 目录中在切换过程中生成的锁文件

测试一下

 

[root@mysql-mha masterha]# rm -rf app1.failover.complete          # 删掉切换锁文件

# 监控程序通过指定配置文件监控 master 状态，当 master 出问题后自动切换并退出避免重复做故障切换

[root@mysql-mha masterha]# masterha_manager --conf=/etc/masterha/app1.cnf

 给mysql-node1添加一个ip，这个ip为172.25.254.155，也就是配置文件中的ip

我们把master上的mysql停掉，看能否自动切换

[root@mysql-mha masterha]# tail -f /etc/masterha/manager.log

九、MySQL高可用集群的VIP管理

上传需要的脚本

[root@mysql-mha masterha]# vim /usr/local/bin/master_ip_failover

[root@mysql-mha masterha]# vim /usr/local/bin/master_ip_online_change 

修改配置文件

为master添加VIP 172.25.254.100

把master上的MySQL停掉

然后我们启动监控并查看日志

VIP跳到了172.25.254.152上了

恢复故障主机

 

这篇关于MySQL 集群：奏响数据交响曲的强大乐章的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---