如何访问k8s集群内部署的mysql服务

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了如何访问k8s集群内部署的mysql服务相关的知识,希望对你有一定的参考价值。

虽然 kubernetes 社区一直在努力使得有状态应用成为一等公民,也推出了 statefulset 控制器支持 pod 的顺序部署,稳定的域名访问和存储访问。但鉴于 mysql 部署运维的多样性和复杂性,在 kubernetes 上部署 MySQL 仍然要面临众多挑战。
1、业务流量入口的配置方式
传统虚拟机环境下,我们通过虚IP的方式,让业务应用都配置事先定义的一个虚IP为链接数据库的地址,然后由高可用服务保证虚IP始终能被路由到master数据库。在kubernetes中,出现了一层网络插件屏蔽了底层网络拓扑,高可用服务管理虚IP的方式需要随之适应调整,比如通过service结合标签完成虚IP的漂移,但service本身是kubernetes提供的一项功能,其可靠性和性能都取决于kubernetes服务的稳定。以性能来说,service是kubeproxy组件通过配置iptables实现的,当iptables规则较多时不可避免的会产生时延,需要我们针对性的解决。
2、容器隔离带来的监控视野问题
在 kubernetes 中,如果将 MySQL 制作为 container 运行在一个 pod 中,container 会将 MySQL 进程和运行环境隔离在一个单独的 namespace 中。监控组件在获取 MySQL 的一些 metirc 时,可能不得不进入与 MySQL 同一个 namespace 中,在部署和设计监控组件时需要考虑到这些限制。
3、存储在 kubernetes 中,支持配置各种不同的存储。
如果使用本地存储 local persistent volume,则需要绑定 MySQL 在一个固定的节点,这就完全浪费了 kubernetes 灵活调度的天然优势;而如果使用远程共享存储,确实是将 MySQL 进程与其存储完全解耦,使得 MySQL 进程可以在任意节点调度,然而考虑到高 I/O 吞吐量的情况,就不是那么美好了。设计时需要考量远程存储是否能够满足 MySQL 的带宽要求。
4、高可用/备份恢复
kubernetes 提供的 statefulset 控制器只能提供最基本的部署,删除功能,无法实现完善的 MySQL 集群高可用/备份恢复操作。对于有状态应用的部署,仍需要定制开发,所以多数公司提供了定制的 operator 来完成应用容器的管理。比如 etcd operator,MySQL operator,后文将为大家详述我测试使用 MySQL operator 的一些记录。
参考技术A 如何访问k8s集群内部署的mysql服务
有两种方法: 直接用yum源进行安装yum -y install mysql-server 源码安装去mysql官网下载你需要的版本,解压,创建用户,/usr/local/mysql5.6/scripts/mysql_install_db --basedir=/usr/local/mysql5.6 --datadir=/data/mysql5.6 --user=mysql本回答被提问者采纳

Mysql MGR 多主模式集群部署

mysql MGR 集群部署

1 部署 MySQL

在集群中的每个节点部署 MySQL

1.1 安装仓库文件

yum install -y http://repo.mysql.com/mysql57-community-release-el7-8.noarch.rpm

1.2 YUM 安装指定版本的 MySQL

yum install -y mysql-community-server-5.7.34-1.el7.x86_64 \\
mysql-community-common-5.7.34-1.el7.x86_64 \\
mysql-community-client-5.7.34-1.el7.x86_64 \\
mysql-community-libs-compat-5.7.34-1.el7.x86_64 \\
mysql-community-libs-5.7.34-1.el7.x86_64

2 初始化数据库

2.1 启动服务

systemctl start mysqld

2.2 设置 root 密码

mysqladmin -uroot -p$(awk '/temporary password/ print $NF' /var/log/mysqld.log) password 自己的密码

3 配置 MySQL

3.1 主机名解析

MGR 中每个节点都必须设置主机名,并且要互相解析,或者设置 DNS 解析。

假如我们目前有 3 台服务器,信息如下

主机名IP
node110.16.24.111
node210.16.24.112
node310.16.24.113

3.2 mysql 配置文件

3.2.1 启动组配置文件内容如下:

必须要添加的关于 MGR 的配置如下

[mysqld]
# MySQL中对于重要热数据的缓存。对于专用服务器,从总RAM的70%开始,否则为10%。
innodb_buffer_pool_size = 1024M

# 删除前导#以设置主要用于报表服务器的选项。
# 对于事务和快速查询,服务器默认值更快。
# 根据需要调整尺寸,试验以找到最佳值。
join_buffer_size = 128M
sort_buffer_size = 2M
read_rnd_buffer_size = 2M
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock

# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0

log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

relay-log-recovery=1
server_id=111
log-bin=mysql-bin
log-slave-updates=ON
binlog-format=row
binlog-checksum=NONE
gtid_mode=ON
enforce_gtid_consistency=ON
master_info_repository=TABLE
relay_log_info_repository=TABLE
transaction-write-set-extraction=XXHASH64
slave_parallel_type=LOGICAL_CLOCK
slave_parallel_workers=4
slave_preserve_commit_order=1

transaction_write_set_extraction = XXHASH64
plugin_load_add='group_replication.so'

group_replication_group_name = 'ce9be252-2b71-11e6-b8f4-00212889f856'
group_replication_start_on_boot = off
group_replication_bootstrap_group = off
group_replication_local_address = 'node1:33061'
group_replication_group_seeds ='node1:33061,node2:33061,node13:33061'

# 关闭单主模式
group_replication_single_primary_mode = off

# 多主模式需要打开,强制检查可能带来风险的操作将直接被拒绝
group_replication_enforce_update_everywhere_checks = on
group_replication_ip_whitelist = 'node1,node2,node3'

3.2.2 配置项介绍

多主模式的组复制必须设置的配置项

server_id=111

log-bin=mysql-bin
log-slave-updates=ON
binlog-format=row
binlog-checksum=NONE

gtid_mode=ON
enforce_gtid_consistency=ON

master_info_repository=TABLE
relay_log_info_repository=TABLE

transaction-write-set-extraction=XXHASH64
plugin_load_add='group_replication.so'

group_replication_group_name = 'ce9be252-2b71-11e6-b8f4-00212889f856'
group_replication_start_on_boot = off
group_replication_bootstrap_group = off

group_replication_local_address = 'node1:33061'
group_replication_group_seeds ='node1:33061,node2:33061,node13:33061'

# 关闭单主模式
group_replication_single_primary_mode = off

# 多主模式需要打开,强制检查可能带来风险的操作将直接被拒绝
group_replication_enforce_update_everywhere_checks = on

3.2.3 集群内其他节点配置文件如下:

这里只展示不一样的地方,其他的都一样

node2的 ⬇️

server_id=112
group_replication_local_address = 'node2:33061'

node3的 ⬇️

server_id=113
group_replication_local_address = 'node3:33061'

4 启动组节点设置并开启 MGR

这里的操作只需要在集群中找到其中一台作为集群中的第一个成员,此成员称为 启动组。

4.1 启动组节点用户授权

mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%' IDENTIFIED BY 'password';
mysql> FLUSH PRIVILEGES;

或者:

mysql> CREATE USER rpl_user@'%' IDENTIFIED BY 'password';
mysql> GRANT REPLICATION SLAVE ON *.* TO rpl_user@'%';
mysql> FLUSH PRIVILEGES;

4.2 为启动组节点设置复制通道

mysql> CHANGE MASTER TO MASTER_USER='rpl_user', MASTER_PASSWORD='password'
FOR CHANNEL 'group_replication_recovery';

4.3 启动组节点开启启动组和开启组复制

mysql> SET GLOBAL group_replication_bootstrap_group=ON;
mysql> START GROUP_REPLICATION;
mysql> SET GLOBAL group_replication_bootstrap_group=OFF;

4.4 为了验证集群的数据同步,场景测试数据,看是否能正常同步到其他成员

CREATE DATABASE test;
CREATE TABLE test.t1 (c1 INT PRIMARY KEY, c2 TEXT NOT NULL);
INSERT INTO test.t1 VALUES (1, 'shark');

5 集群其他成员开启 MGR

5.1 设置组复制通道连接信息

CHANGE MASTER TO MASTER_USER='rpl_user', 
MASTER_PASSWORD='password'  FOR CHANNEL 'group_replication_recovery';

5.2 开启组复制

START GROUP_REPLICATION;

6 验证组内成员

SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE  |
+---------------------------+--------------------------------------+-------------+-------------+---------------+
| group_replication_applier | 395409e1-6dfa-11e6-970b-00212844f856 |   node1        |        3306 | ONLINE        |
| group_replication_applier | ac39f1e6-6dfa-11e6-a69d-00212844f856 |   node2        |        3306 | ONLINE        |
| group_replication_applier | fe90f134-6dfa-11e6-a69d-00212844f856 |   node2        |        3306 | ONLINE        |
+---------------------------+--------------------------------------+-------------+-------------+---------------+

6 排错

日志错误输出:

2021-08-01T21:29:39.162214Z 3 [ERROR] Plugin group_replication reported: ‘Binlog must be enabled for Group Replication’

原因: 没有开启 binlog 日志

解决: 修改配置文件,添加 binlog 的配置

log_bin=binlog

2 日志错误输出:

2021-08-01T21:52:01.641762Z 10 [ERROR] Plugin group_replication reported: ‘There was an error when connecting to the donor server. Please check that group_replication_recovery channel credentials and all MEMBER_HOST column values of performance_schema.replication_group_members table are correct and DNS resolvable.’

原因: 没有设置 DNS 解析,服务器插件无法解析主机名

解决: 给集群中的每台服务器设置 DNS 解析或者设置本地 DNS 解析(/etc/hosts)

3 日志错误输出:

2021-08-01T22:36:05.135368Z 0 [ERROR] Plugin group_replication reported: ‘This member has more executed transactions than those present in the group. Local transactions: bbc4f604-f317-11eb-9d94-5254009263a6:1 > Group transactions: 1d234308-f2cf-11eb-88d7-525400a538ee:1-2, 2d814f0c-fdd5-5e44-9edb-c003d40281fc:1-2’

原因:

slave执行的事务gtid与master不一致,如果只是因为误操作,或者是一些无关紧要的数据,可以通过set globalgroup_replication_allow_local_disjoint_gtids_join=on;来忽略这些事务,或者通过reset master清空gtidexecuted表然后重新设置gtid purged参数跟master的gtid executed一致来跳过这些事务。如果这些数据不一致会导致问题那么可以通过pt-table-sync来检查误差数据并同步,然后再通过reset master等操作重设gtid相关参数,需要注意的是这个工具需要binlog格式为statment以使slave也能执行同样检查语句。

解决:

mysql> reset master;

以上是关于如何访问k8s集群内部署的mysql服务的主要内容,如果未能解决你的问题,请参考以下文章

Kubernetes 部署 Mysql 8

高可用集群篇-- K8S部署微服务

企业级k8s集群部署

k8s部署mongo集群

云原生之kubernetes实战在k8s集群环境下部署Tomcat应用

K8S部署apollo配置中心