银河麒麟V10 SP3 X86 二进制文件部署 mysql-5.7.29 GTID 半同步复制的双主架构

简介: 银河麒麟V10 SP3 X86 二进制文件部署 mysql-5.7.29 GTID 半同步复制的双主架构
  • 麒麟镜像可以去下面的地方下载,需要自己注册一个账号

啰嗦一下

  • 老生常谈的问题(这些问题都会影响部署的排查)
  • 关掉 firewalld
  • 关掉 selinux (银河麒麟默认会关闭 selinux)

我下载的海光 x86 版本的麒麟

NAME="Kylin Linux Advanced Server"
VERSION="V10 (Lance)"
ID="kylin"
VERSION_ID="V10"
PRETTY_NAME="Kylin Linux Advanced Server V10 (Lance)"
ANSI_COLOR="0;31"

mysql 的 AB 复制和 gtid 复制的优缺点

抄自 opengpt 3.5

在 MySQL 中,有两种常见的复制方式:AB 复制(Asynchronous Replication)和 GTID 复制(Global Transaction Identifier Replication)。

AB 复制(Asynchronous Replication)

优点

  1. 简单易用:AB 复制是 MySQL 复制的最基本形式,设置相对简单,适合初学者或简单复制场景。
  2. 性能:因为是异步复制,主数据库不需要等待从数据库的确认,所以主库的写操作可以更快地完成,提高了主库的性能。
  3. 容错:在出现网络故障或从库延迟时,主库不会受到影响,继续提供服务。

缺点:

  1. 数据延迟:因为是异步复制,从库的数据可能会有一定的延迟,这意味着在主库上提交的事务不会立即在从库上可见。
  2. 数据一致性:由于延迟,主从之间的数据可能会出现不一致的情况,这需要开发者自行处理。
  3. 单点故障:如果主库故障,需要手动切换到备库,造成一定的停机时间。
GTID 复制(Global Transaction Identifier Replication)

优点:

  1. 数据一致性:使用 GTID,每个事务都有全局唯一的标识符,确保主从之间的数据一致性,避免数据冲突。
  2. 简化拓扑结构:GTID 复制使得添加或删除节点更加容易,不需要像传统复制那样配置复杂的 master-host 和 master-log-position。
  1. 自动故障转移:GTID 复制可以更容易地实现自动故障转移,当主库发生故障时,可以自动切换到从库。

缺点:

  1. 性能:由于 GTID 需要维护全局唯一标识符,可能会对性能产生一定的影响,尤其在高负载的情况下。
  2. 配置复杂性:相比 AB 复制,GTID 复制的配置较为复杂,特别是在现有的非 GTID 复制架构迁移到 GTID 复制时,需要谨慎处理。
  1. 兼容性:GTID 复制要求 MySQL 版本在 5.6 以上,如果要使用较旧的 MySQL 版本,可能不支持 GTID。
  • AB 复制适合简单的数据复制和备份需求,对数据一致性和高可用性要求不高的场景。
  • GTID 复制适合对数据一致性和高可用性要求较高的复制架构,尤其在复杂的拓扑结构和自动故障转移场景中更加有优势。选择哪种复制方式取决于应用程序的需求和系统的复杂性。

mysql gtid 并行复制和半同步复制的优缺点

在 MySQL GTID 主从复制中,还有两种复制模式:并行复制和半同步复制。这两种模式可以进一步提高复制的性能和数据一致性。让我们来看一下它们的优缺点和利弊:

并行复制(Parallel Replication)

优点:

  1. 提高复制性能:并行复制允许在从库上同时执行多个线程来处理不同的事务,从而提高了复制的性能和吞吐量。
  2. 减少延迟:通过并行执行事务,从库可以更快地赶上主库,从而减少数据复制的延迟。
  3. 多核利用:现代服务器通常有多个核心,使用并行复制可以更好地利用这些多核心,加快数据复制。

缺点:

  1. 复杂性增加:并行复制的配置和管理相对复杂,可能需要更多的系统资源和监控,不适合所有环境。
  2. 并发控制:并行复制可能导致数据在不同线程之间的冲突和竞争,需要开发者正确处理并发控制问题。
半同步复制(Semi-Synchronous Replication)

优点:

  1. 数据安全性:半同步复制确保至少一个从库已经确认接收并写入主库的事务,从而提高数据的安全性和一致性。
  2. 高可用性:在主库发生故障时,由于至少有一个从库已经复制了主库的数据,可以更快地将从库提升为新的主库,减少停机时间。
  3. 监控机制:半同步复制提供了可以监控从库复制进度的机制,使得管理员可以更好地了解复制的状态和延迟情况。

缺点:

  1. 性能影响:由于需要等待至少一个从库确认写入,半同步复制可能对主库的性能产生一定的影响,特别是在写入负载较高的情况下。
  2. 单点故障:如果配置了多个从库,并且至少一个从库确认写入的要求,那么当所有从库都不可用时,主库的写入将会受阻。

综合考虑

  • 并行复制适用于高负载环境,可以显著提高复制性能和减少复制延迟,但配置和管理相对较复杂。
  • 半同步复制适用于对数据安全性和高可用性要求较高的场景,但可能会对主库的性能产生一定的影响。选择哪种模式取决于具体的应用需求和系统性能情况。

准备两台虚拟机,我们启航

好戏开场

部署 mysql

  • 下面的操作,都是使用的 root 用户,但是 mysql 使用的是普通用户
  • 部署 mysql 是两台虚拟机都需要安排的
创建 mysql 启动的用户

创建的 mysql 用户就分配一个 nologin 的 shell,不给登录机器的

useradd mysql -s /sbin/nologin
创建 mysql 安装包存放路径
mkdir -p /data/software/mysql

上传或者下载 mysql 二进制文件到 /data/software/mysql 下后进行解压,这里就不体现步骤了

下面的命令给 mysql 二进制文件修改用户权限,让 mysql 用户有权限可以读取

chown -R mysql /data/software/mysql/mysql-5.7.29-linux-glibc2.12-x86_64
创建主库 mysql 配置文件

我这边就用了 GTID 的半同步模式

  • 创建对应的目录 [两台机器都需要创建]
mkdir -p /data/mysql/{mysql_data,logs,config}
  • 在 mysql 主库上创建配置文件
cat << EOF > /data/mysql/config/my.cnf
[mysqld]
pid-file=/data/mysql/mysqld.pid
socket=/data/mysql/mysqld.sock
datadir=/data/mysql/mysql_data
log-error=/data/mysql/logs/error.log
port=13306
# MySQL 在运行时需要 errmsg.sys 文件来显示和报告错误消息
lc-messages-dir=/data/software/mysql/mysql-5.7.29-linux-glibc2.12-x86_64/share/english
# GTID
## 每个 mysql 的 server_id 不能重复
server_id=135
# 新事务和复制事务都必须是 GTID 事务
gtid_mode=on
# 不允许任何事务违反 GTID 一致性
enforce_gtid_consistency=on
# MySQL 在启动时会跳过启动从服务器的复制线程,从而暂时禁止从服务器执行复制任务
skip_slave_start=1
# binlog
# binlog 文件的名称
log_bin=mysql-bin
# 设置每个二进制日志文件的最大大小
max_binlog_size=100m
# 设置用于缓存二进制日志事件的缓冲区大小
binlog_cache_size=4m
# 设置 binlog 缓存的最大大小
max_binlog_cache_size=512m
# binlog 类型
binlog_format=ROW
# binlog 过期时间
expire_logs_days=7
# binlog 记录忽略的数据库
binlog-ignore-db=sys,mysql,performance_schema,information_schema
# 从服务器将主服务器的更新记录到自己的 binlog 里面
log-slave-updates=ON
# 每次提交事务时,等待将日志写入磁盘并返回成功后才继续执行
sync_binlog=1
# 配置半同步复制使用的插件
plugin-load="rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
# 开启半同步复制
rpl_semi_sync_master_enabled=ON
rpl_semi_sync_slave_enabled=ON
bind-address=0.0.0.0
# 是否允许在数据库目录下使用符号链接
## symbolic-links=0:表示不允许使用符号链接。如果设置为 0,MySQL 服务器在启动时将不会使用数据库目录下的符号链接,并且可能会在符号链接存在时报错。
## symbolic-links=1:表示允许使用符号链接。如果设置为 1,MySQL 服务器在启动时将允许使用数据库目录下的符号链接,但仅限于特定目录或文件(根据权限设置)。
## symbolic-links=2:表示允许使用符号链接,且没有限制。如果设置为 2,MySQL 服务器在启动时将允许使用数据库目录下的任意符号链接,包括对任意文件或目录的链接。
symbolic-links=0
# mysql 最大连接数
max_connections=1000
# 默认存储引擎
default_storage_engine=innodb
# 禁用外部锁定,MySQL 将使用内部锁定来代替外部锁定
skip_external_locking
# 0:表名存储为原始大小写,区分大小写;
# 1:表名存储为小写,不区分大小写;
# 2:表名存储为小写,但会在文件系统上进行名称比较,因此会区分大小写。
lower_case_table_names=1
# 禁用主机缓存,每次都要重新解析域名
skip_host_cache
# 开启主机名解析
skip_name_resolve
# 设置服务器的默认字符集
character_set_server=utf8
# 客户端与服务器之间允许的最大数据包大小
max_allowed_packet=12M
# 控制 SQL 的执行模式
## STRICT_TRANS_TABLES:启用严格模式,对于事务表,如果有非法数据插入或更新,将会引发错误
## NO_ZERO_IN_DATE:禁止在日期中使用 "0000-00-00" 这样的零值,否则会被转换为 NULL 值
## ERROR_FOR_DIVISION_BY_ZERO:当除零错误发生时,产生错误而不是返回 NULL 值
## NO_AUTO_CREATE_USER:禁止 GRANT 语句自动创建新用户,必须手动创建
## NO_ENGINE_SUBSTITUTION:如果指定的存储引擎不可用或不存在,不要自动替换为其他可用的存储引擎,而应该返回错误
sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'
[client]
# 设置 MySQL 客户端连接的默认字符集
character-set-client=utf8
EOF
创建从库 mysql 配置文件
  • 在 mysql 从库上创建配置文件
  • 注意 service_id 要和主库的不一样
cat << EOF > /data/mysql/config/my.cnf
[mysqld]
pid-file=/data/mysql/mysqld.pid
socket=/data/mysql/mysqld.sock
datadir=/data/mysql/mysql_data
log-error=/data/mysql/logs/error.log
port=13306
lc-messages-dir=/data/software/mysql/mysql-5.7.29-linux-glibc2.12-x86_64/share/english
server_id=136
gtid_mode=on
enforce_gtid_consistency=on
skip_slave_start=1
log_bin=mysql-bin
max_binlog_size=100m
binlog_cache_size=4m
max_binlog_cache_size=512m
binlog_format=ROW
expire_logs_days=7
binlog-ignore-db=sys,mysql,performance_schema,information_schema
log-slave-updates=ON
sync_binlog=1
plugin-load="rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
rpl_semi_sync_master_enabled=ON
rpl_semi_sync_slave_enabled=ON
bind-address=0.0.0.0
symbolic-links=0
max_connections=1000
default_storage_engine=innodb
skip_external_locking
lower_case_table_names=1
skip_host_cache
skip_name_resolve
character_set_server=utf8
max_allowed_packet=12M
sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'
[client]
character-set-client=utf8
EOF

修改文件和目录的用户权限

chown -R mysql /data/mysql
chown -R mysql /data/software/mysql/mysql-5.7.29-linux-glibc2.12-x86_64
mysql 初始化
mysqld --initialize-insecure \
--user=mysql \
--basedir=/data/software/mysql/mysql-5.7.29-linux-glibc2.12-x86_64 \
--datadir=/data/mysql/mysql_data
创建 systemcl 管理
cat << EOF > /usr/lib/systemd/system/mysqld.service
[Unit]
After=network.target
After=syslog.target
[Install]
WantedBy=multi-user.target
[Service]
User=mysql
Type=forking
TimeoutSec=0
PermissionsStartOnly=true
ExecStart=/data/software/mysql/mysql-5.7.29-linux-glibc2.12-x86_64/bin/mysqld \\
          --defaults-file=/data/mysql/config/my.cnf --daemonize \\
          --plugin-dir=/data/software/mysql/mysql-5.7.29-linux-glibc2.12-x86_64/lib/plugin
LimitNOFILE=5000
Restart=on-failure
RestartPreventExitStatus=1
PrivateTmp=false
EOF

启动 mysql

systemctl daemon-reload
systemctl enable mysqld
systemctl start mysqld

进入 mysql 验证

初始化的时候没有带密码,进入 mysql 不需要密码,直接回车就可以了

mysql -uroot -p -S /data/mysql/mysqld.sock
  • 以下的操作没有特殊提示,均在 mysql 内操作
修改 root 用户密码
SET PASSWORD FOR root@localhost = PASSWORD ('abc123');

配置互为主从

从库配置主从关系

主库创建复制用户

CREATE USER 'rpldb'@'%' IDENTIFIED BY 'rpldb007';
GRANT REPLICATION SLAVE ON *.* TO 'rpldb'@'%';

主库查看 binlog 名称和 Position 信息

SHOW MASTER STATUS\G

获取到类似如下的信息

*************************** 1. row ***************************
             File: mysql-bin.000001
         Position: 841
     Binlog_Do_DB:
 Binlog_Ignore_DB: sys,mysql,performance_schema,information_schema
Executed_Gtid_Set: c5b4fcf9-3699-11ee-845e-000c29db9ce6:1-3

从库配置主从,下面的 ip 和用户名,密码,binlog 文件名称和 Position 都要替换成自己实际的信息

CHANGE MASTER TO MASTER_HOST='172.72.0.135', MASTER_PORT=13306, MASTER_USER='rpldb', MASTER_PASSWORD='rpldb007', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=841;

启动复制

START SLAVE;

查看 slave 情况

SHOW SLAVE STATUS\G

看到这两个都是 yes,表示主从复制已经建立成功了

Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
主库配置互为主从关系

从库创建复制用户

CREATE USER 'rpldb'@'%' IDENTIFIED BY 'rpldb007';
GRANT REPLICATION SLAVE ON *.* TO 'rpldb'@'%';

从库查看 binlog 名称和 Position 信息

SHOW MASTER STATUS\G

获取到类似如下的信息

*************************** 1. row ***************************
             File: mysql-bin.000001
         Position: 841
     Binlog_Do_DB:
 Binlog_Ignore_DB: sys,mysql,performance_schema,information_schema
Executed_Gtid_Set: 1d31ccb1-369d-11ee-bff2-000c29cd48ee:1-3

主库配置互为主从,下面的 ip 和用户名,密码,binlog 文件名称和 Position 都要替换成自己实际的信息

CHANGE MASTER TO MASTER_HOST='172.72.0.136', MASTER_PORT=13306, MASTER_USER='rpldb', MASTER_PASSWORD='rpldb007', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=841;

启动复制

START SLAVE;

查看 slave 情况

SHOW SLAVE STATUS\G

看到这两个都是 yes,表示主从复制已经建立成功了

Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

验证主从复制

主库创建一个测试数据

-- 建库
CREATE DATABASE replication_test;
-- 进入到库里
USE replication_test;
-- 建表
CREATE TABLE replication_test.slt(
  num int auto_increment primary key,
  name char(10),
  job char(10),
  age int,
  salary int,
  descrip char(128)not null default ''
)charset=utf8;
-- 插入数据
INSERT INTO replication_test.slt(name, job, age, salary,descrip) VALUES
('Tom','teacher',30,20000,'level2'),
('frank','teacher',31,21000,'level2'),
('jack','teacher',32,22000,'level2'),
('jhon','asistant',23,8000,'level3'),
('hugo','manager',45,30000,'level4'),
('jinhisan','teacher',26,9000,'level1');

主库查看一下数据

SELECT * FROM replication_test.slt WHERE name='Tom';

获取到如下的信息

+-----+------+---------+------+--------+---------+
| num | name | job     | age  | salary | descrip |
+-----+------+---------+------+--------+---------+
|   1 | Tom  | teacher |   30 |  20000 | level2  |
+-----+------+---------+------+--------+---------+

可以在从库看一下,同样可以获取到一样的信息

模拟主库故障

通过停止主库的服务来模拟出现故障,然后在从库继续写入数据,验证主库修复后,是否会建立数据同步

systemctl stop mysqld

在从库内看同步情况,可以看到 Slave_IO_Running 变成了 Connecting 状态

在从库内继续写入数据

INSERT INTO replication_test.slt(name, job, age, salary,descrip) VALUES
('Rose','teacher',30,20000,'level1'),
('Maybe','manager',28,30000,'level4');

重新启动宕机的 mysql 服务

systemctl start mysqld

启动宕机 mysql 的复制

START SLAVE;

查看 slave 情况,看到 Slave_IO_RunningSlave_SQL_Running 都是 yes 即可

SHOW SLAVE STATUS\G

宕机恢复的节点进行数据查看,验证数据是否同步

SELECT * from replication_test.slt WHERE name='Maybe';

可以正常获取到数据,证明互为主从没毛病

+-----+-------+---------+------+--------+---------+
| num | name  | job     | age  | salary | descrip |
+-----+-------+---------+------+--------+---------+
|   8 | Maybe | manager |   28 |  30000 | level4  |
+-----+-------+---------+------+--------+---------+


相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。 &nbsp; 相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情:&nbsp;https://www.aliyun.com/product/rds/mysql&nbsp;
目录
相关文章
|
存储 机器学习/深度学习 数据库
阿里云服务器X86/ARM/GPU/裸金属/超算五大架构技术特点、场景适配参考
在云计算技术飞速发展的当下,云计算已经渗透到各个行业,成为企业数字化转型的关键驱动力。选择合适的云服务器架构对于提升业务效率、降低成本至关重要。阿里云提供了多样化的云服务器架构选择,包括X86计算、ARM计算、GPU/FPGA/ASIC、弹性裸金属服务器以及高性能计算等。本文将深入解析这些架构的特点、优势及适用场景,以供大家了解和选择参考。
1719 61
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
存储 SQL 关系型数据库
MySQL进阶突击系列(03) MySQL架构原理solo九魂17环连问 | 给大厂面试官的一封信
本文介绍了MySQL架构原理、存储引擎和索引的相关知识点,涵盖查询和更新SQL的执行过程、MySQL各组件的作用、存储引擎的类型及特性、索引的建立和使用原则,以及二叉树、平衡二叉树和B树的区别。通过这些内容,帮助读者深入了解MySQL的工作机制,提高数据库管理和优化能力。
|
关系型数据库 MySQL 分布式数据库
Super MySQL|揭秘PolarDB全异步执行架构,高并发场景性能利器
阿里云瑶池旗下的云原生数据库PolarDB MySQL版设计了基于协程的全异步执行架构,实现鉴权、事务提交、锁等待等核心逻辑的异步化执行,这是业界首个真正意义上实现全异步执行架构的MySQL数据库产品,显著提升了PolarDB MySQL的高并发处理能力,其中通用写入性能提升超过70%,长尾延迟降低60%以上。
|
负载均衡 算法 关系型数据库
大数据新视界--大数据大厂之MySQL数据库课程设计:MySQL集群架构负载均衡故障排除与解决方案
本文深入探讨 MySQL 集群架构负载均衡的常见故障及排除方法。涵盖请求分配不均、节点无法响应、负载均衡器故障等现象,介绍多种负载均衡算法及故障排除步骤,包括检查负载均衡器状态、调整算法、诊断修复节点故障等。还阐述了预防措施与确保系统稳定性的方法,如定期监控维护、备份恢复策略、团队协作与知识管理等。为确保 MySQL 数据库系统高可用性提供全面指导。
|
存储 机器学习/深度学习 算法
阿里云X86/ARM/GPU/裸金属/超算等五大服务器架构技术特点、场景适配与选型策略
在我们选购阿里云服务器的时候,云服务器架构有X86计算、ARM计算、GPU/FPGA/ASIC、弹性裸金属服务器、高性能计算可选,有的用户并不清楚他们之间有何区别。本文将深入解析这些架构的特点、优势及适用场景,帮助用户更好地根据实际需求做出选择。
|
存储 机器学习/深度学习 应用服务中间件
阿里云服务器架构解析:从X86到高性能计算、异构计算等不同架构性能、适用场景及选择参考
当我们准备选购阿里云服务器时,阿里云提供了X86计算、ARM计算、GPU/FPGA/ASIC、弹性裸金属服务器以及高性能计算等多种架构,每种架构都有其独特的特点和适用场景。本文将详细解析这些架构的区别,探讨它们的主要特点和适用场景,并为用户提供选择云服务器架构的全面指南。
1409 18
|
JSON 数据格式 Python
X86架构属于国产化架构吗
在信息时代,处理器架构至关重要。本文通过简单流程和代码示例,帮助初学者理解X86架构是否属于国产化架构。首先明确国产化架构指本土研发的处理器架构,如龙芯、飞腾等。X86架构由Intel设计,主要由外资公司开发,通常不被视为国产架构。文章提供了一个判断X86架构是否国产化的流程图,并用Python代码实现判断过程。Architecture类描述架构来源和类型,App类负责获取和判定架构信息。通过这些步骤,初学者可以更好地掌握相关知识并提升开发技能。
1514 5
|
SQL 存储 缓存
MySQL的架构与SQL语句执行过程
MySQL架构分为Server层和存储引擎层,具有高度灵活性和可扩展性。Server层包括连接器、查询缓存(MySQL 8.0已移除)、分析器、优化器和执行器,负责处理SQL语句;存储引擎层负责数据的存储和读取,常见引擎有InnoDB、MyISAM和Memory。SQL执行过程涉及连接、解析、优化、执行和结果返回等步骤,本文详细讲解了一条SQL语句的完整执行过程。
710 3
|
机器学习/深度学习 弹性计算 人工智能
阿里云服务器ECS架构区别及选择参考:X86计算、ARM计算等架构介绍
在我们选购阿里云服务器的时候,云服务器架构有X86计算、ARM计算、GPU/FPGA/ASIC、弹性裸金属服务器、高性能计算可选,有的用户并不清楚他们之间有何区别,本文主要简单介绍下这些架构各自的主要性能及适用场景,以便大家了解不同类型的架构有何不同,主要特点及适用场景有哪些。
2317 10

推荐镜像

更多