1. statefullset部署mysql主从集群的原理

运行一个有状态的应用程序
mysql-0是master
mysql-1和mysql-2是两个备份
当mysql写的时候，找headless service中的mysql-0.mysql；当mysql读的时候，找clusterip service中的mysql读，实现读写分离。
statefulset维护三个副本，一个主两个从
因为主从的配置不同所以通过configmap来解决主从配置不同的问题

如何使用StatefulSet 控制器去运行一个有状态的应用程序。此例是一主多从的 MySQL 集群

部署 MySQL 示例，包含一个 ConfigMap，两个 Services，与一个 StatefulSet

（1）从以下的 YAML 配置文件创建 ConfigMap

configmap（作用配置文件和镜像解藕）

apiVersion: v1
kind: ConfigMap
metadata:name: mysqllabels:app: mysql
data:master.cnf: |# Apply this config only on the master.[mysqld]log-binslave.cnf: |# Apply this config only on slaves.[mysqld]super-read-only

这个 ConfigMap 提供 my.cnf 覆盖，使您可以独立控制 MySQL 主服务器和从服务器的配置。在这种情况下，您希望主服务器能够将复制日志提供给从服务器，并且希望从服务器拒绝任何不是通过复制进行的写操作。

ConfigMap 本身没有什么特别之处，它可以使不同部分应用于不同的 Pod。每个 Pod 都会决定在初始化时要看基于 StatefulSet 控制器提供的信息。

（2）从以下 YAML 配置文件创建服务

apiVersion: v1
kind: Service
metadata:name: mysqllabels:app: mysql
spec:ports:- name: mysqlport: 3306clusterIP: Noneselector:app: mysql
---
# Client service for connecting to any MySQL instance for reads.
# For writes, you must instead connect to the master: mysql-0.mysql.
apiVersion: v1
kind: Service
metadata:name: mysql-readlabels:app: mysql
spec:ports:- name: mysqlport: 3306selector:app: mysql

Headless Service 给 StatefulSet 控制器为集合中每个 Pod 创建的 DNS 条目提供了一个宿主。因为 Headless Service 名为 mysql，所以可以通过在同一 Kubernetes 集群和 namespace 中的任何其他 Pod 内解析 .mysql来访问 Pod。

客户端 Service 称为 mysql-read，是一种常规 Service，具有其自己的群集 IP，该群集 IP 在报告为就绪的所有MySQL Pod 中分配连接。可能端点的集合包括 MySQL 主节点和所有从节点。

请注意，只有读取查询才能使用负载平衡的客户端 Service。因为只有一个 MySQL 主服务器，所以客户端应直接连接到 MySQL 主服务器 Pod (通过其在 Headless Service 中的 DNS 条目)以执行写入操作。

（3）最后，从以下 YAML 配置文件创建 StatefulSet pod

[kubeadm@server1 mysql]$ cat statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:name: mysql
spec:selector:matchLabels:app: mysqlserviceName: mysqlreplicas: 3template:metadata:labels:app: mysqlspec:initContainers:             //pod初始化阶段，第一个初始化容器- name: init-mysqlimage: reg.westos.org/k8s/mysql:5.7command:- bash- "-c"- |set -ex# Generate mysql server-id from pod ordinal index.[[ `hostname` =~ -([0-9]+)$ ]] || exit 1ordinal=${BASH_REMATCH[1]}echo [mysqld] > /mnt/conf.d/server-id.cnf# Add an offset to avoid reserved server-id=0 value.echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf# Copy appropriate conf.d files from config-map to emptyDir.if [[ $ordinal -eq 0 ]]; thencp /mnt/config-map/master.cnf /mnt/conf.d/elsecp /mnt/config-map/slave.cnf /mnt/conf.d/fivolumeMounts:- name: confmountPath: /mnt/conf.d- name: config-mapmountPath: /mnt/config-map- name: clone-mysql            //第二个初始化容器，主从复制image: reg.westos.org/k8s/xtrabackup:1.0command:- bash- "-c"- |set -ex# Skip the clone if data already exists.[[ -d /var/lib/mysql/mysql ]] && exit 0# Skip the clone on master (ordinal index 0).[[ `hostname` =~ -([0-9]+)$ ]] || exit 1ordinal=${BASH_REMATCH[1]}[[ $ordinal -eq 0 ]] && exit 0# Clone data from previous peer.ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql# Prepare the backup.xtrabackup --prepare --target-dir=/var/lib/mysqlvolumeMounts:- name: datamountPath: /var/lib/mysqlsubPath: mysql- name: confmountPath: /etc/mysql/conf.dcontainers:- name: mysql                   //第一个容器mysqlimage: reg.westos.org/k8s/mysql:5.7env:- name: MYSQL_ALLOW_EMPTY_PASSWORDvalue: "1"ports:- name: mysqlcontainerPort: 3306volumeMounts:- name: datamountPath: /var/lib/mysqlsubPath: mysql- name: confmountPath: /etc/mysql/conf.dresources:requests:cpu: 500mmemory: 1GilivenessProbe:exec:command: ["mysqladmin", "ping"]initialDelaySeconds: 30periodSeconds: 10timeoutSeconds: 5readinessProbe:exec:# Check we can execute queries over TCP (skip-networking is off).command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"]initialDelaySeconds: 5periodSeconds: 2timeoutSeconds: 1- name: xtrabackup             //第二个容器备份image: reg.westos.org/k8s/xtrabackup:1.0ports:- name: xtrabackupcontainerPort: 3307command:- bash- "-c"- |set -excd /var/lib/mysql# Determine binlog position of cloned data, if any.if [[ -f xtrabackup_slave_info && "x$(<xtrabackup_slave_info)" != "x" ]]; then# XtraBackup already generated a partial "CHANGE MASTER TO" query# because we're cloning from an existing slave. (Need to remove the tailing semicolon!)cat xtrabackup_slave_info | sed -E 's/;$//g' > change_master_to.sql.in# Ignore xtrabackup_binlog_info in this case (it's useless).rm -f xtrabackup_slave_info xtrabackup_binlog_infoelif [[ -f xtrabackup_binlog_info ]]; then# We're cloning directly from master. Parse binlog position.[[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1rm -f xtrabackup_binlog_info xtrabackup_slave_infoecho "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.infi# Check if we need to complete a clone by starting replication.if [[ -f change_master_to.sql.in ]]; thenecho "Waiting for mysqld to be ready (accepting connections)"until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; doneecho "Initializing replication from clone position"mysql -h 127.0.0.1 \-e "$(<change_master_to.sql.in), \MASTER_HOST='mysql-0.mysql', \MASTER_USER='root', \MASTER_PASSWORD='', \MASTER_CONNECT_RETRY=10; \START SLAVE;" || exit 1# In case of container restart, attempt this at-most-once.mv change_master_to.sql.in change_master_to.sql.origfi# Start a server to send backups when requested by peers.exec ncat --listen --keep-open --send-only --max-conns=1 3307 -c \"xtrabackup --backup --slave-info --stream=xbstream --host=127.0.0.1 --user=root"volumeMounts:- name: datamountPath: /var/lib/mysqlsubPath: mysql- name: confmountPath: /etc/mysql/conf.dresources:requests:cpu: 100mmemory: 100Mivolumes:- name: confemptyDir: {}- name: config-mapconfigMap:name: mysqlvolumeClaimTemplates:- metadata:name: dataspec:accessModes: ["ReadWriteOnce"]resources:requests:storage: 10Gi
[kubeadm@server1 mysql]$

可以通过运行以下命令查看启动进度：

kubectl get pods -l app=mysql --watch

一段时间后，您应该看到所有3个 Pod 都开始运行

NAME      READY     STATUS    RESTARTS   AGE
mysql-0   2/2       Running   0          2m
mysql-1   2/2       Running   0          1m
mysql-2   2/2       Running   0          1m

该清单使用多种技术来管理作为 StatefulSet 一部分的有状态 Pod。下一节重点介绍其中一些技巧，以解释 StatefulSet 创建 Pod 时发生的状况

StatefulSet 控制器一次按顺序启动 Pod 序数索引。它一直等到每个 Pod 报告就绪为止，然后再开始下一个 Pod。

此外，控制器为每个 Pod 分配一个唯一，稳定的表单名称

<statefulset-name>-<ordinal-index>

其结果是 Pods 名为 mysql-0，mysql-1 和 mysql-2。

上述 StatefulSet 清单中的 Pod 模板利用这些属性来执行 MySQL 复制的有序启动。

在启动 Pod 规范中的任何容器之前， Pod 首先运行任何初始容器按照定义的顺序。

第一个名为 init-mysql 的初始化容器，根据序号索引生成特殊的 MySQL 配置文件。

该脚本通过从 Pod 名称的末尾提取索引来确定自己的序号索引，该名称由 hostname 命令返回。然后将序数(带有数字偏移量以避免保留值)保存到 MySQL conf.d 目录中的文件 server-id.cnf 中。这将转换 StatefulSet 提供的唯一，稳定的身份控制器进入需要相同属性的 MySQL 服务器 ID 的范围。

通过将内容复制到 conf.d 中，init-mysql 容器中的脚本也可以应用 ConfigMap 中的 master.cnf 或 slave.cnf。由于示例拓扑由单个 MySQL 主节点和任意数量的从节点组成，因此脚本仅将序数 0 指定为主节点，而将其他所有人指定为从节点。与 StatefulSet 控制器的部署顺序保证,这样可以确保 MySQL 主服务器在创建从服务器之前已准备就绪，以便它们可以开始复制。

通常，当新的 Pod 作为从节点加入集合时，必须假定 MySQL 主节点可能已经有数据。还必须假设复制日志可能不会一直追溯到时间的开始。这些保守假设的关键是允许正在运行的 StatefulSet 随时间扩大和缩小而不是固定在其初始大小。

第二个名为 clone-mysql 的初始化容器，第一次在从属 Pod 上以空 PersistentVolume 启动时，会对从属 Pod 执行克隆操作。这意味着它将从另一个运行的 Pod 复制所有现有数据，因此其本地状态足够一致，可以开始主从服务器复制。

MySQL 本身不提供执行此操作的机制，因此该示例使用了一种流行的开源工具 Percona XtraBackup。在克隆期间，源 MySQL 服务器可能会降低性能。为了最大程度地减少对 MySQL 主机的影响，该脚本指示每个 Pod 从序号较低的 Pod 中克隆。可以这样做的原因是 StatefulSet 控制器始终确保在启动 Pod N + 1 之前 Pod N 已准备就绪。

初始化容器成功完成后，常规容器将运行。 MySQL Pods 由运行实际 mysqld 服务器的 mysql 容器和充当辅助工具的 xtrabackup 容器组成。

xtrabackup 辅助工具查看克隆的数据文件，并确定是否有必要在从属服务器上初始化 MySQL 复制。如果是这样，它将等待 mysqld 准备就绪，然后执行带有从 XtraBackup 克隆文件中提取的复制参数 CHANGE MASTER TO 和 START SLAVE 命令。

一旦从服务器开始复制后，它会记住其 MySQL 主服务器。并且如果服务器重新启动或连接中断，则会自动重新连接。另外，因为从服务器会以其稳定的 DNS 名称查找主服务器(mysql-0.mysql)，即使由于重新安排而获得新的 Pod IP，他们也会自动找到主服务器。

最后，开始复制后，xtrabackup 容器监听来自其他 Pod 的连接数据克隆请求。如果 StatefulSet 扩大规模，或者下一个 Pod 失去其 PersistentVolumeClaim 并需要重新克隆，则此服务器将无限期保持运行。

写：

在master写
在slave读

kubernetes(k8s)：使用statefulset部署mysql主从集群相关推荐

k8s（七）—statefullset部署mysql主从集群
1 使用statefullset部署mysql主从集群 mysql-0是master mysql-1和mysql-2是两个备份当mysql写的时候,找headless service中的mysql- ...
OpenShift 4 之 GitOps（6）用ArgoCD部署MongoDB主从集群
<OpenShift 4.x HOL教程汇总> 文章目录部署架构部署MongoDB主从集群准备操作环境配置ArgoCD 准备MongoDB所需证书更新被部署的YAML文件在三个 ...
MySQL主从集群原理+实战
目录如下 MySQL主从集群原理+实战背景随着公司业务的发展,对数据库的要求越来越高,以前的单机MySQL肯定是玩不转了,亟需升级成MySQL集群,这是一个公司在业务发展时不得不面临的问题就单机 ...
innodb 集群_部署MySQL InnoDB集群以实现高可用性
innodb 集群 In this article, I am going to explain how we can deploy the MySQL InnoDB cluster. InnoDB ...
使用docker compose部署MySQL主从复制集群
使用docker compose部署MySQL主从复制集群环境说明宿主机:Ubuntu 14.04.6 LTS Docker Engine: 18.06.3-ce docker compose: ...
在 Kubernetes 中基于 StatefulSet 部署 MySQL（下）
大家好,我是老 Z! 上篇文章实现了 MySQL 数据库在基于 KubeSphere 部署的 K8s 集群上的安装部署,部署方式采用了图形化界面这种形式.本文将会介绍如何使用 GitOps 来部署 M ...
docker 搭建mysql 连接不上_docker搭建MySQL主从集群
关于MySQL主从模式,如果我们直接在本机上搭建的话,是没法搭建的,只能借助于虚拟机,但有的时候我们又需要搭建一个主从集群,以便于进行一些功能性的测试.这个时候我们就可以尝试使用docker,借助于d ...
mysql gtid 集群_Docker搭建MySQL主从集群，基于GTID
写在前边搭建MySQL读写分离主从集群,这里未使用binlog方式,使用的是GTID方式源码见我的Github https://github.com/hellxz/mysql-cluster-do ...
k8s使用statefulset部署mysql一主多从集群_k8s部署mysql集群南
部署原理 1.准备环境服务器2核4G 139.198.38.94 139.198.41.101 139.198.31.125 需要提前准备好NFS挂载,此处用的是静态nfs #所有机器安装 yum ...
k8s使用statefulset部署mysql一主多从集群
部署原理 1.准备环境服务器2核4G 139.198.38.94 139.198.41.101 139.198.31.125 需要提前准备好NFS挂载,此处用的是静态nfs #所有机器安装 yum ...

kubernetes(k8s)：使用statefulset部署mysql主从集群

文章目录

1. statefullset部署mysql主从集群的原理

（1）从以下的 YAML 配置文件创建 ConfigMap

（2）从以下 YAML 配置文件创建服务

（3）最后，从以下 YAML 配置文件创建 StatefulSet pod

kubernetes(k8s)：使用statefulset部署mysql主从集群相关推荐

最新文章

热门文章