跳转到内容

Percona XtraDB Cluster (PXC) 面试题

30 道题
分类
数据库
子分类
mysql
题目数
30 道
已阅读 0 / 30 题
1 PXC 的架构与 Galera 同步复制原理

答案:

PXC 基于 Galera Replication 插件实现多主同步复制,集群中每个节点均可读写,事务在提交前通过写集合(Write-Set)在所有节点间进行认证,确保数据强一致性。

[分层展开]

  • 多主架构:每个节点拥有完整数据副本,任意节点可接受读写请求,无需主从切换
  • 同步复制:事务在源节点执行到 commit 阶段时,将写集合广播至集群内所有节点进行认证,认证通过后源节点提交,其余节点异步 apply
  • 虚拟同步:Galera 的同步指认证阶段的同步(certification-based replication),非 2PC 意义上的同步提交,实际 apply 与应用 relay log 类似
  • 数据路径:客户端 -> MySQL Server 层 -> InnoDB 事务 -> wsrep API -> Galera Replication Plugin -> gcomm 后端(Group Communication)-> 网络广播
  • 认证机制:每个写集合携带全局事务 ID(Global Transaction ID, GTID),各节点在 certification index 中检查冲突,无冲突则 apply,有冲突则回滚本地事务
+------------------+       Write-Set        +------------------+
|   Node 1 (PXC)   | <---------------------> |   Node 2 (PXC)   |
|  MySQL + Galera  |                         |  MySQL + Galera  |
|  + wsrep Provider|                         |  + wsrep Provider|
+--------+---------+                         +--------+---------+
         |                                            |
         |          Group Communication (gcomm)        |
         +--------------------------------------------+
                              |
                    +------------------+
                    |   Node 3 (PXC)   |
                    |  MySQL + Galera  |
                    |  + wsrep Provider|
                    +------------------+

核心组件:

组件作用
wsrep APIMySQL/Galera 接口层,拦截事务并提取写集合
Galera Replication Plugin写集合认证、复制、apply
gcomm / gcsGroup Communication System,组成员通信与消息排序
gcache写集合缓存,用于 IST 增量同步
2 PXC 的流控(Flow Control)机制

答案:

PXC 流控通过调节各节点的写入速率,防止慢节点因 apply 速度跟不上而被写集合队列淹没,避免队列过长导致事务延迟急剧上升或节点从集群中被驱逐。

[分层展开]

  • 触发条件:节点 receive queue 中等待 apply 的写集合数量超过 gcs.fc_limit(默认 16),或队列大小超过 gcs.fc_factor(默认 1.0)倍的平均队列
  • 流控信号:触发流控的节点向集群广播 FC_PAUSE 消息,集群内所有节点暂停发送新事务,直到 FC_RESUME 消息到达
  • 关键参数:
    • wsrep_slave_threads:apply 线程数,增大可加快 apply 速度,降低流控频率
    • gcs.fc_limit:流控队列阈值,调大可容忍更大延迟但可能增加 apply 积压
    • gcs.fc_factor:动态流控因子,控制流控灵敏度
    • gcs.fc_master_slave:启用后仅主节点(写入节点)响应流控
  • 监控指标:wsrep_flow_control_paused_ns 反映流控暂停累计时间,wsrep_flow_control_recv 记录接收到的流控事件数
-- 查看流控状态
SHOW STATUS LIKE 'wsrep_flow_control%';

-- 查看接收队列长度
SHOW STATUS LIKE 'wsrep_local_recv_queue%';

-- 调整流控参数(运行时)
SET GLOBAL wsrep_slave_threads = 4;

优化方向:提高磁盘 I/O 性能、增加 wsrep_slave_threads、升级硬件以降低 apply 延迟、使用更低延迟的网络。

3 PXC 的节点状态与集群视图

答案:

PXC 节点在生命周期中经历多个状态转换,通过 wsrep_local_state_comment 和 wsrep_cluster_status 反映当前节点及集群的整体健康状态。

[分层展开]

节点状态(wsrep_local_state_comment):

状态值说明
Joining1节点正在加入集群,处于 SST/IST 阶段
Donor/Desynced2节点作为 SST 数据源,不接受客户端请求
Joined3节点已完成数据同步,但尚未完成最终校验
Synced4节点完全正常运行,可接受读写

集群状态(wsrep_cluster_status):

状态说明
Primary集群正常,存在仲裁多数派(quorum)
Non-Primary集群分裂或节点数不足,无法形成仲裁,拒绝所有写操作

关键监控变量:

-- 查看节点完整 wsrep 状态
SHOW GLOBAL STATUS LIKE 'wsrep%';

-- 关键字段
-- wsrep_cluster_state_uuid     : 集群唯一标识
-- wsrep_cluster_size            : 集群当前节点数
-- wsrep_cluster_status          : Primary / Non-Primary
-- wsrep_local_state_comment     : Synced / Donor / Joining
-- wsrep_ready                   : ON 表示节点可接受查询
-- wsrep_connected               : ON 表示与集群通信正常

集群视图(Cluster View):每一次成员变更(节点加入或离开)都会生成新的视图 ID(view ID),所有节点对该视图达成一致后,事务可以继续在新视图下进行。

4 PXC 的 SST(State Snapshot Transfer)vs IST(Incremental State Transfer)

答案:

SST 是节点的全量数据同步方式,将 Donor 节点的完整数据快照传输给 Joiner;IST 是增量同步方式,仅传输 Joiner 缺失的那部分写集合缓存数据。

[分层展开]

对比:

维度SSTIST
数据量全量数据集仅缺失的增量写集合
适用场景新节点加入、数据差异过大节点短暂断开后重连
触发条件gcache 中无 Joiner 缺失的 seqnogcache 中存在 Joiner 缺失的全部 seqno
性能影响大,Donor 进入 Desynced 状态小,增量数据量通常有限
传输方式xtrabackup / mysqldump / rsync直接从 gcache 环形缓冲区读取
耗时分钟至小时级(取决于数据量)秒至分钟级
Donor 负载高,需全量导出低,仅需读取 gcache

SST 方法:

方法特点
xtrabackup物理备份,速度快,Donor 端非阻塞,推荐
xtrabackup-v2xtrabackup 的增强版,支持 GTID
mysqldump逻辑备份,速度慢,Donor 端阻塞,仅适合小型库
rsync直接文件复制,最快但要求同版本二进制
cloneMySQL 8.0 clone 插件,物理克隆,速度快
# my.cnf 配置 SST
[mysqld]
wsrep_sst_method = xtrabackup-v2
wsrep_sst_auth = "sstuser:sstpassword"

适用场景:IST 优先,SST 作为 IST 不可用时的回退方案。生产环境配置 gcache.size 足够大以覆盖绝大多数节点重连场景。

5 PXC 的 gcache 机制与作用

答案:

gcache 是 PXC 节点内存中的写集合环形缓冲区,缓存最近写入的写集合数据,用于 IST 增量同步,避免短时断开后的全量 SST。

[分层展开]

  • 结构:gcache 由固定大小的环形缓冲区(ring buffer)构成,文件映射形式存储在磁盘上
  • 核心参数:
    • gcache.size:gcache 总大小,决定可缓存多少写集合
    • gcache.page_size:page 文件大小,gcache 溢出到磁盘时的分页单元
    • gcache.keep_pages_size:可保留在内存中的 page 总量
  • 淘汰策略:新写集合写入时,最旧的写集合被覆盖,循环使用缓冲空间
  • IST 依赖:Joiner 所需的 seqno 必须在 gcache 范围内,否则回退到 SST
  • 大小估算:
# gcache.size = (每小时写入量 × 最大允许停机时间) / 压缩比
# 示例:100GB/h 写入,允许停机 2h,压缩比 3:1
# gcache.size ≈ 200GB / 3 ≈ 67GB
[mysqld]
wsrep_provider_options = "gcache.size=2G;gcache.page_size=128M"

调优建议:生产环境 gcache.size 设置为覆盖至少 2-4 小时写入量,使用 SSD 存储 gcache.page 文件以降低磁盘 I/O 瓶颈。

6 PXC 的写集合(Write-Set)认证与复制

答案:

PXC 在事务提交前,将事务所涉及的行级变更封装为写集合,广播至集群中所有节点进行冲突检测(certification),认证通过后源节点提交,其余节点异步 apply。

[分层展开]

  • 写集合生成:wsrep API 拦截 InnoDB 事务的变更操作,提取每行的主键、旧值(before image)和新值(after image),构成写集合
  • 广播与排序:gcomm 层使用基于全局序列号(seqno)的全序广播(total order broadcast)协议,确保所有节点以相同顺序接收写集合
  • 认证过程:
    1. 目标节点将写集合中的主键与 certification index 中已认证但尚未 apply 的事务进行比对
    2. 若存在冲突(主键重合且写集合不兼容),目标事务被回滚并返回死锁错误
    3. 若无冲突,写集合插入 certification index,事务 apply 后从 index 中移除
  • 冲突处理:客户端收到 ERROR 1213 (40001): Deadlock found when trying to get lock,业务层必须实现重试逻辑
  • 乐观复制:先执行后认证(commit 前认证),区别于悲观锁的预检测机制
事务执行流程:
1. BEGIN
2. 执行 DML 语句(本地执行,InnoDB 写 undo/redo log)
3. COMMIT -> wsrep 拦截,提取写集合
4. 写集合广播至集群所有节点
5. 各节点并行认证(certification)
6. 认证通过 -> 源节点 commit + 其余节点 apply
7. 认证失败 -> 源节点 rollback + 返回死锁错误

适用场景:高冲突工作负载(如热点行更新)应谨慎评估 PXC 适用性,必要时将热点数据路由到同一节点写入。

7 PXC 在 Kubernetes 上的部署架构(Percona Operator)

答案:

Percona Operator for MySQL 将 PXC 部署为 Kubernetes StatefulSet,每个 Pod 包含 PXC 实例容器、ProxySQL/HAProxy sidecar、备份 sidecar 和 PMM 监控 agent,通过 CR 声明式管理集群生命周期。

[分层展开]

  • Operator 架构:PerconaXtraDBCluster CRD -> Operator Controller -> StatefulSet / Service / ConfigMap / Secret / PVC
  • 核心容器:
    • pxc:Percona XtraDB Cluster 主容器
    • proxysql 或 haproxy:负载均衡 sidecar,提供集群入口
    • backup:备份 sidecar,通过 xtrabackup 定期备份到 S3 兼容存储
    • pmm-client:Percona Monitoring and Management agent
  • 服务发现:Operator 自动创建 Headless Service 用于节点间通信,ClusterIP Service 供客户端连接
  • 存储:每节点绑定独立的 PVC(PersistentVolumeClaim),StatefulSet 保证 Pod 重建后数据不丢
# PerconaXtraDBCluster CR 示例
apiVersion: pxc.percona.com/v1
kind: PerconaXtraDBCluster
metadata:
  name: cluster1
spec:
  crVersion: 1.15.0
  pxc:
    size: 3
    image: percona/percona-xtradb-cluster:8.0
    volumeSpec:
      persistentVolumeClaim:
        resources:
          requests:
            storage: 100Gi
  proxysql:
    size: 3
    image: percona/percona-xtradb-cluster-operator:1.15.0-proxysql
  backup:
    image: percona/percona-xtradb-cluster-operator:1.15.0-pxc8.0-backup
    storages:
      s3-us-east:
        type: s3
        s3:
          bucket: pxc-backups
          region: us-east-1

节点流量路由:

                    Service (ClusterIP)
                           |
              +------------+-----------+
              |            |           |
         ProxySQL-0   ProxySQL-1   ProxySQL-2
              |            |           |
         PXC Pod-0    PXC Pod-1    PXC Pod-2
        (Writer)     (Reader)     (Reader)
              \          |           /
               Galera Group Communication
8 PXC 的备份与恢复策略

答案:

PXC 备份以 xtrabackup 物理热备份为主,Percona Operator 内置定时备份调度并上传至 S3 兼容对象存储;恢复时从 S3 拉取备份,通过 SST 机制重建集群节点。

[分层展开]

备份方案:

工具类型特点适用场景
xtrabackup物理热备份非阻塞、压缩、增量备份支持生产首选
mysqldump逻辑备份阻塞、输出 SQL 文本、速度慢小型库或逻辑迁移
mysqlbackupMySQL Enterprise物理备份、加密企业版环境
S3 对象存储远程存储Operator 自动上传,支持定时调度K8s 环境

Operator 备份配置:

spec:
  backup:
    image: percona/percona-xtradb-cluster-operator:1.15.0-pxc8.0-backup
    schedule:
      - name: daily-backup
        schedule: "0 2 * * *"
        keep: 7
        storageName: s3-us-east
    storages:
      s3-us-east:
        type: s3
        s3:
          bucket: pxc-backups
          region: us-east-1

恢复流程:

# 1. 从 S3 下载最新备份
# 2. 准备备份(apply-log)
xtrabackup --prepare --target-dir=/backup/

# 3. 启动新节点(自动触发 SST 加入集群)
# 4. 或通过 Operator 从备份恢复:
kubectl apply -f restore.yaml

# restore.yaml
apiVersion: pxc.percona.com/v1
kind: PerconaXtraDBClusterRestore
metadata:
  name: restore-daily
spec:
  pxcCluster: cluster1
  backupName: daily-backup

RPO/RTO:定时备份频率决定 RPO(建议每日全备 + 每小时增量),SST 恢复时间决定 RTO(取决于数据量)。

9 PXC 的监控指标与 Prometheus 集成

答案:

PXC 原生暴露 Prometheus metrics 端点,通过 Percona Monitoring and Management(PMM)或直接 Prometheus 采集 wsrep 状态、MySQL 性能指标和 Galera 复制指标。

[分层展开]

核心监控指标分类:

类别指标说明
集群健康wsrep_cluster_size集群节点数
集群健康wsrep_cluster_statusPrimary / Non-Primary
节点状态wsrep_local_state4=Synced, 3=Joined, 2=Donor, 1=Joining
节点状态wsrep_ready是否可接受查询
流控wsrep_flow_control_paused_ns累计流控暂停纳秒数
流控wsrep_flow_control_recv接收到的流控事件数
复制延迟wsrep_local_recv_queue本地接收队列大小
复制延迟wsrep_local_recv_queue_avg平均接收队列大小
复制延迟wsrep_apply_window认证与 apply 的时间窗口
冲突wsrep_local_bf_aborts本地因冲突被回滚的事务数
冲突wsrep_local_cert_failures本地认证失败次数
流量wsrep_received_bytes接收的 wsrep 数据量
流量wsrep_replicated_bytes发送的 wsrep 数据量

Prometheus 集成:

# ServiceMonitor 示例
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: pxc-monitor
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: percona-xtradb-cluster
  endpoints:
    - port: metrics
      interval: 30s

告警规则示例:

groups:
  - name: pxc_alerts
    rules:
      - alert: PXCNodeNotSynced
        expr: mysql_global_status_wsrep_local_state != 4
        for: 2m
        annotations:
          summary: "PXC 节点 {{ $labels.pod }} 状态异常"

      - alert: PXCClusterNonPrimary
        expr: mysql_global_status_wsrep_cluster_status != 0
        for: 1m
        annotations:
          summary: "PXC 集群进入 Non-Primary 状态"

      - alert: PXCFlowControlPaused
        expr: rate(mysql_global_status_wsrep_flow_control_paused_ns[5m]) > 0.1
        for: 5m
        annotations:
          summary: "PXC 流控暂停比例过高"
10 PXC 与 ProxySQL 的集成

答案:

ProxySQL 作为 PXC 集群的智能负载均衡层,提供读写分离、连接池、查询路由、故障隔离和查询缓存能力,避免应用直接感知集群拓扑变化。

[分层展开]

  • 读写分离:ProxySQL 通过 mysql_query_rules 将读写请求分别路由到 Writer 组和 Reader 组
  • 故障检测:ProxySQL 定期执行 mysql-monitor_galera_healthcheck 脚本检测节点状态,自动将故障节点从路由表移除
  • 连接池:ProxySQL 维护与后端 PXC 节点的连接池,减少连接开销,支持连接复用
  • 查询缓存:对高频只读查询在 ProxySQL 层缓存结果

ProxySQL 核心配置表:

-- 定义后端 PXC 节点
INSERT INTO mysql_servers (hostgroup_id, hostname, port, weight, max_connections)
VALUES (10, 'pxc-node-0.pxc', 3306, 1, 1000),
       (10, 'pxc-node-1.pxc', 3306, 1, 1000),
       (10, 'pxc-node-2.pxc', 3306, 1, 1000);

-- 读写分离规则
INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, apply)
VALUES (1, 1, '^SELECT.*', 10, 1),       -- 读请求路由至 Reader 组
       (2, 1, '^INSERT|^UPDATE|^DELETE', 10, 1); -- 写请求路由至 Writer 组

-- Galera 健康检查用户
SET mysql-monitor_username = 'monitor';
SET mysql-monitor_password = 'monitor_password';
SET mysql-monitor_galera_healthcheck = 1;

-- 加载配置到运行时
LOAD MYSQL SERVERS TO RUNTIME;
LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;
SAVE MYSQL QUERY RULES TO DISK;

Percona Operator 集成:Operator 自动管理 ProxySQL 配置,节点变更时自动更新 mysql_servers 表,无需手动维护。

11 PXC 的 HAProxy vs ProxySQL 负载均衡对比

答案:

HAProxy 是 L4/L7 高性能反向代理,适合简单 TCP 负载均衡场景;ProxySQL 是数据库专用代理,提供查询路由、读写分离、连接缓存等数据库层智能。

[分层展开]

维度HAProxyProxySQL
层级L4(TCP)/ L7(HTTP)L7(MySQL Protocol)
读写分离需监听不同端口或健康检查脚本原生支持,基于查询规则
连接池不支持(TCP 透传)支持,可大幅降低后端起连压力
查询缓存不支持支持,可缓存高频只读查询
查询路由仅支持端口/地址级路由支持按 SQL 模式、用户、schema 匹配路由
延迟开销极低(TCP 转发)略高(需解析 MySQL 协议)
故障检测基础 TCP 检查Galera 专用健康检查,感知节点状态
配置复杂度低中,管理表较多
适用场景高吞吐、简单负载均衡复杂路由、读写分离、连接池需求

选择建议:

  • 高并发简单负载均衡场景:HAProxy
  • 需要读写分离、连接池、查询路由:ProxySQL
  • 同集群混合部署:HAProxy 作为外部入口,ProxySQL 作为内部智能路由

HAProxy 配置示例:

frontend pxc_frontend
    bind *:3306
    default_backend pxc_backend

backend pxc_backend
    balance roundrobin
    option httpchk GET /check
    server pxc-node-0 pxc-node-0.svc:3306 check port 9200 inter 2s
    server pxc-node-1 pxc-node-1.svc:3306 check port 9200 inter 2s
    server pxc-node-2 pxc-node-2.svc:3306 check port 9200 inter 2s
12 PXC 的脑裂(Split-Brain)处理机制

答案:

PXC 基于权重仲裁(Weighted Quorum)防止脑裂:当集群分裂时,仅大多数节点分区可继续操作(Primary),少数分区自动降级为 Non-Primary 并拒绝所有写入。

[分层展开]

  • 仲裁规则:每个节点拥有一个投票权重(pc.weight,默认 1),分区中权重之和 > 集群总权重的 50% 时该分区保持 Primary
  • Non-Primary 行为:降级分区中的节点主动拒绝客户端写请求,返回 ERROR 1047 (08S01): Unknown command,确保数据一致性
  • 网络分区恢复:分区恢复后,少数分区节点自动从多数分区获取增量数据(IST 优先)或全量数据(SST),重新加入集群
  • 权重配置策略:
    • 单数据中心 3 节点:各节点权重相等(1,1,1),任一节点可与其余构成多数
    • 跨数据中心:主数据中心节点分配较高权重,确保主数据中心在分区中获取 Primary
# 在 my.cnf 中配置节点权重
[mysqld]
wsrep_provider_options = "pc.weight=2"

仲裁计算示例:

场景节点数总权重多数要求分区 A 权重分区 B 权重结果
3 节点等权33>1.521A=Primary, B=Non-Primary
5 节点等权55>2.532A=Primary, B=Non-Primary
跨 DC,4 节点46>34 (DC1)2 (DC2)DC1=Primary, DC2=Non-Primary
13 PXC 的最小集群节点数与仲裁机制

答案:

PXC 最小部署为 3 个节点以保证高可用,两节点集群存在脑裂风险;仲裁机制通过节点投票确保仅多数派分区可为 Primary。

[分层展开]

  • 最小节点数:奇数个节点(3、5、7 等)是最佳实践,避免平票问题
  • 2 节点风险:任一节点故障导致剩余节点无法形成多数(50% 不构成多数),整个集群进入 Non-Primary
  • 4 节点:可容忍 1 节点故障(3/4 > 50%),但无法容忍 2 节点同时故障(2/4 = 50%)
  • 5 节点:可容忍 2 节点故障(3/5 > 50%)
  • 仲裁机制(PC:Primary Component):
    • 集群启动时运行 PC bootstrap 协议,确定主组件
    • 主组件运行期间通过 weight-based quorum 维护
    • 当主组件中节点故障导致权重不足,整个组件降级
-- 查看当前集群 views 和仲裁状态
SHOW STATUS LIKE 'wsrep_cluster_size';
SHOW STATUS LIKE 'wsrep_cluster_status';
SHOW STATUS LIKE 'wsrep_provider_name';
SHOW STATUS LIKE 'wsrep_provider_vendor';

Garbd 仲裁守护进程:可在独立轻量节点运行 garbd(Galera Arbitrator Daemon),仅参与投票不存储数据,避免 2 节点集群的平票问题,或为偶数节点集群提供"决胜票"。

# 启动 garbd
garbd --group=pxc_cluster --address="gcomm://10.0.0.1,10.0.0.2" \
      --option="pc.weight=1"
14 PXC 的 2PC(两阶段提交)支持

答案:

PXC 通过 Galera 对 XA 事务的有限支持实现分布式两阶段提交,允许跨多个存储引擎执行原子事务,但受限于 Galera 的乐观复制模型,XA 事务在 PXC 中存在严格约束。

[分层展开]

  • XA 事务流程:XA START -> DML 操作 -> XA END -> XA PREPARE -> XA COMMIT / XA ROLLBACK
  • 约束:
    • XA 事务跨越的存储引擎必须都支持 XA(InnoDB 原生支持)
    • XA PREPARE 阶段引入额外写入放大(每个分支产生独立写集合)
    • 认证发生在 XA COMMIT 阶段,而非 XA PREPARE
    • 仅支持同一节点内跨引擎 XA,不支持跨节点分布式事务
  • 写入放大:XA 事务在 prepare 阶段在每个参与节点产生写集合,导致 2 倍以上的网络开销
-- XA 事务示例
XA START 'xid1';
INSERT INTO orders VALUES (1, 'order_data');
INSERT INTO orders_archive VALUES (1, 'order_data');
XA END 'xid1';
XA PREPARE 'xid1';
XA COMMIT 'xid1';

适用场景:单节点内需要保证跨表原子操作的场景。跨节点分布式事务应使用应用层 Saga 模式或两阶段提交协调器,而非直接依赖 PXC 的 XA 支持。

15 PXC 的 DDL 复制方式(TOI/RSU)

答案:

PXC 提供两种 DDL 执行模式:TOI(Total Order Isolation)以全局顺序在所有节点同步执行 DDL,保证一致性;RSU(Rolling Schema Upgrade)仅在本地节点执行 DDL,适合在线 schema 变更。

[分层展开]

维度TOI(Total Order Isolation)RSU(Rolling Schema Upgrade)
执行范围全局所有节点同步执行仅本地节点执行
一致性DDL 执行期间阻塞所有 DMLDDL 执行期间本节点仍可执行 DML
可用性DDL 期间集群全局暂停写入DDL 期间仅本节点写入暂停
适用场景小表、快速 DDL大表在线 DDL、滚动升级
风险长时间 DDL 导致集群全局不可写DDL 期间其他节点的 DML 可能产生冲突
控制方式默认模式,wsrep_OSU_method=TOI需显式设置 wsrep_OSU_method=RSU

操作示例:

-- TOI 模式(默认)
ALTER TABLE large_table ADD COLUMN new_col INT;
-- 全局所有节点同时执行,阻塞 DML 直到完成

-- RSU 模式
SET GLOBAL wsrep_OSU_method = 'RSU';
ALTER TABLE large_table ADD COLUMN new_col INT;
SET GLOBAL wsrep_OSU_method = 'TOI';
-- 仅本地节点执行,执行完成后逐节点重复操作

-- 检查当前模式
SHOW VARIABLES LIKE 'wsrep_OSU_method';

最佳实践:

  • 小表 DDL(<1s):直接使用 TOI
  • 大表 DDL:逐节点 RSU + 工具辅助(pt-online-schema-change、gh-ost)
  • pt-online-schema-change 与 PXC 兼容,自动处理 TOI/RSU 切换
16 PXC 的 4 节点以上拓扑设计

答案:

4 节点以上 PXC 部署用于读扩展和跨机房容灾,关键设计包括写入节点收敛、读负载均衡策略、跨区域延迟控制和仲裁票数分配。

[分层展开]

拓扑模型:

           +----------+          +----------+
           |  PXC-1   |          |  PXC-2   |
           | (DC1-R1) |          | (DC1-R2) |
           +----+-----+          +-----+----+
                |                      |
                |   Galera Replication |
     +----------+----------+----------+----------+
     |          |          |          |          |
+----+----+ +---+----+ +---+----+ +---+----+
|  PXC-3  | | PXC-4  | | PXC-5  | | PXC-6  |
| DC2-R1  | | DC2-R2 | | DC3-R1  | | DC3-R2  |
+---------+ +--------+ +--------+ +--------+

设计要点:

维度策略
写入目标单一节点写入(通过 ProxySQL 规则),避免多节点写入导致的冲突概率上升
读取负载读请求均匀分布至所有节点,线性扩展读吞吐
仲裁权重不同 DC 分配差异化权重,确保主 DC 在网络分区时获取 Primary
跨区域延迟节点间 RTT 控制在 10ms 以内,超过此值考虑分段仲裁配置
节点数量推荐 3/5/7 奇数节点,偶数节点需配合 garbd 消除平票

段仲裁(Segment):

# DC1 节点
wsrep_provider_options = "gmcast.segment=1;pc.weight=2"
# DC2 节点
wsrep_provider_options = "gmcast.segment=2;pc.weight=1"
# DC3 节点
wsrep_provider_options = "gmcast.segment=3;pc.weight=1"

Segment 配置使 Donor 选择优先在本地段进行,降低跨 DC SST 流量。

17 PXC 的跨数据中心部署方案

答案:

PXC 跨数据中心部署通过 Segmented Group Communication 和权重仲裁实现地理分布高可用,节点按物理位置分组为 Segment,SST/IST 优先在同 Segment 内完成。

[分层展开]

部署架构:

                  ProxySQL VIP
                       |
            +----------+----------+
            |                     |
    +-------+--------+   +-------+--------+
    |   Data Center 1 |   |   Data Center 2 |
    |  (Primary Site) |   | (Disaster Rec.) |
    +-----------------+   +-----------------+
    | PXC-1 (w=2,s=1) |   | PXC-3 (w=1,s=2) |
    | PXC-2 (w=2,s=1) |   | PXC-4 (w=1,s=2) |
    +-----------------+   +-----------------+
            |                     |
            +---- WAN Link -------+

配置策略:

配置项主 DC(DC1)备 DC(DC2)
gmcast.segment12
pc.weight21
gcache.size4h 写入量4h 写入量
evs.inactive_check_periodPT0.5SPT0.5S
evs.suspect_timeoutPT5SPT5S
evs.inactive_timeoutPT15SPT15S

关键考量:

  • 跨 DC 延迟(RTT)< 5ms 时可作为同步集群运行
  • 延迟 5-30ms 时需调整超时参数并接受性能折损
  • 延迟 > 30ms 不建议跨 DC 同步复制,改用异步复制方案
  • 备 DC 节点权重低于主 DC,确保网络分区时主 DC 成为 Primary

客户端路由:通过 Geo-DNS 或 GSLB 将客户端路由至最近 ProxySQL 端点,本地读取,写入路由至主 DC。

18 PXC 的性能优化与参数调优

答案:

PXC 性能优化围绕减少写集合大小、降低流控频率、优化网络传输和协调 InnoDB 与 Galera 参数展开。

[分层展开]

核心参数调优:

参数建议值作用
wsrep_slave_threadsCPU 核心数 × 2提高 apply 并发度
innodb_flush_log_at_trx_commit2降低磁盘 I/O,容忍 1s 数据丢失
innodb_autoinc_lock_mode2跨节点 auto_inc 兼容,避免自增锁冲突
binlog_formatROWGalera 要求,写集合依赖行格式
wsrep_provider_options见下多项组合调优
innodb_buffer_pool_size物理内存 70-80%缓存热数据

Provider Options 调优:

[mysqld]
wsrep_provider_options = "
  gcache.size=4G;
  gcs.fc_limit=32;
  gcs.fc_factor=0.8;
  gcs.max_packet_size=64500;
  evs.inactive_check_period=PT1S;
  evs.suspect_timeout=PT10S;
  evs.inactive_timeout=PT30S;
  evs.keepalive_period=PT3S
"

写入优化:

  • 批量插入使用 INSERT INTO … VALUES (…), (…), (…),减少写集合数量
  • 避免大事务,拆分超过 10 万行的批量操作
  • 降低 wsrep_max_ws_size 防止超大写集合导致内存溢出

网络优化:

# 增大网络缓冲区
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216

冲突规避:将相同行的写入路由至同一节点,降低跨节点冲突概率。

19 PXC 的故障恢复流程

答案:

PXC 节点故障恢复分为节点自动重加入、集群整体重启和灾难恢复三种场景,核心流程依赖 Galera 的 IST/SST 机制和 PC bootstrap 协议。

[分层展开]

场景一:单节点故障 - 自动重加入

1. 节点故障(崩溃、网络断开)
2. 其余节点维持 Primary,集群正常运行
3. 故障节点恢复,检测到 gcache 覆盖的 seqno 范围
4. 优先 IST:从集群节点拉取增量事务
5. 否则 SST:从 Donor 节点拉取全量快照
6. 节点状态 Joining -> Joined -> Synced

场景二:集群整体停机 - Bootstrap

# 1. 确认最后运行的节点(拥有最高 seqno)
# 在每个节点上执行
mysqld --wsrep-recover

# 2. 查看最后一个节点输出的 seqno(grastate.dat 或错误日志):
cat /var/lib/mysql/grastate.dat
# seqno: 12345

# 3. 以 bootstrap 模式启动 seqno 最高的节点(设为 safe_to_bootstrap: 1)
# 在 grastate.dat 中设置后再启动,或直接:
mysqld --wsrep-new-cluster

# 4. 其余节点正常启动,自动加入集群
systemctl start mysql

场景三:灾难恢复 - S3 备份恢复

# 1. 从 S3 拉取最新备份
aws s3 cp s3://pxc-backups/latest/ /backup/

# 2. 准备备份
xtrabackup --prepare --target-dir=/backup/

# 3. 初始化节点数据目录
rm -rf /var/lib/mysql/*
xtrabackup --copy-back --target-dir=/backup/

# 4. 创建 grastate.dat
echo "safe_to_bootstrap: 1" > /var/lib/mysql/grastate.dat

# 5. 启动 bootstrap 节点
mysqld --wsrep-new-cluster

# 6. 其余节点从备份节点的 SST 恢复

故障恢复 SLA 评估:

故障类型RTO恢复方式
单节点 crash数秒 ~ 数分钟IST 自动恢复
单节点长时间离线分钟 ~ 小时SST 自动恢复
集群全停数分钟手动 bootstrap
数据中心故障数分钟 ~ 小时手动 bootstrap + S3 恢复
20 PXC 与 Group Replication(InnoDB Cluster)对比

答案:

PXC 基于 Galera(Percona 分支)实现多主同步复制,Group Replication 是 MySQL 原生插件基于 Paxos 协议的单主/多主同步方案;二者均支持多主写入,但在性能特性、冲突检测和生态工具上有显著差异。

[分层展开]

维度PXCGroup Replication / InnoDB Cluster
复制协议Galera(virtually synchronous)Paxos(Group Communication System)
多主写入原生支持,所有节点等权支持多主模式,配置复杂
冲突检测乐观认证(certification)乐观认证(certification)
SST/IST原生支持仅支持 MySQL Clone 插件
流控基于队列长度的 f-low control基于事务延迟的 flow control
写集合基于行的 write-set基于行的 certification info
最小节点数3(推荐)3(单主模式 1 也可)
异步从库支持异步 slave 挂载支持(Group Replication + Async)
MySQL 版本Percona Server(MySQL 分支)MySQL 5.7.17+ / 8.0+
DDL 复制TOI / RSU 两种模式仅支持原子 DDL(8.0+)
运维工具Percona Toolkit, PMM, OperatorMySQL Shell, MySQL Router
K8s OperatorPercona Operator for MySQLMySQL Operator for Kubernetes

选择依据:

场景推荐方案
多活写入、对等节点PXC
MySQL 官方支持、单主场景Group Replication
需要 ProxySQL 读写分离PXC
需要 MySQL Router 原生路由InnoDB Cluster
K8s 部署、备份调度集成PXC(Percona Operator 更成熟)
21 PXC 的备份工具(xtrabackup vs mysqldump)

答案:

xtrabackup 是 Percona 开发的物理热备份工具,非阻塞、支持增量备份和压缩,是 PXC 生产环境首选;mysqldump 是 MySQL 原生逻辑备份工具,输出 SQL 文本,适合小型库和逻辑迁移。

[分层展开]

维度xtrabackupmysqldump
备份类型物理(数据文件 + redo log)逻辑(SQL 语句)
阻塞性非阻塞(短暂 FTWRL 或 backup lock)阻塞(读锁,–single-transaction 可缓解)
速度快(直接拷贝文件)慢(逐行转 SQL)
增量备份支持(基于 LSN)不支持
压缩原生支持(–compress)需通过 pipe 到 gzip
输出格式二进制文件可读 SQL 文本
恢复灵活性必须恢复到相同版本/架构可跨版本、跨引擎
PXC SST 集成原生(xtrabackup-v2)支持(mysqldump SST)
数据量级TB 级建议 50GB 以下

xtrabackup 使用示例:

# 全量备份
xtrabackup --backup --target-dir=/backup/full --user=root --password=xxx

# 增量备份(基于上一次全量/增量)
xtrabackup --backup --target-dir=/backup/inc1 \
           --incremental-basedir=/backup/full \
           --user=root --password=xxx

# 准备备份(apply-log)
xtrabackup --prepare --apply-log-only --target-dir=/backup/full
xtrabackup --prepare --apply-log-only --target-dir=/backup/full \
           --incremental-dir=/backup/inc1

# 恢复
xtrabackup --copy-back --target-dir=/backup/full

mysqldump 使用示例:

# 单事务备份(PXC 专用参数)
mysqldump --single-transaction \
          --skip-lock-tables \
          --all-databases \
          --routines --triggers --events \
          > /backup/dump.sql

选择依据:生产环境全量 + 增量策略使用 xtrabackup;小型测试环境、跨版本数据迁移使用 mysqldump。

22 PXC 的 SSL/TLS 加密配置

答案:

PXC 支持三层 SSL/TLS 加密:Galera 节点间通信加密(gcomm)、SST 传输加密和 MySQL 客户端连接加密,生产环境应按要求启用全部三层。

[分层展开]

加密层级:

层级配置项范围
Galera 通信socket.ssl_key / socket.ssl_cert / socket.ssl_ca节点间 gcomm 加密
SST 传输sst 选项 + xtrabackup SSLSST 数据传输加密
客户端连接MySQL SSL(常规配置)应用连接加密

Galera 节点间加密:

[mysqld]
wsrep_provider_options = "
  socket.ssl_key=/etc/mysql/certs/server-key.pem;
  socket.ssl_cert=/etc/mysql/certs/server-cert.pem;
  socket.ssl_ca=/etc/mysql/certs/ca-cert.pem;
  socket.ssl_cipher=AES128-SHA256
"

SST 加密:

[mysqld]
wsrep_sst_method = xtrabackup-v2
wsrep_sst_auth = "sstuser:sstpassword"

[sst]
encrypt = 4  # xtrabackup 加密算法(AES256)
ssl-mode = VERIFY_CA
ssl-ca = /etc/mysql/certs/ca-cert.pem
ssl-cert = /etc/mysql/certs/server-cert.pem
ssl-key = /etc/mysql/certs/server-key.pem

客户端连接加密:

[mysqld]
ssl-ca = /etc/mysql/certs/ca-cert.pem
ssl-cert = /etc/mysql/certs/server-cert.pem
ssl-key = /etc/mysql/certs/server-key.pem
require_secure_transport = ON

证书生成:

# 生成 CA
openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 3650 -key ca-key.pem -out ca-cert.pem

# 生成 Server 证书
openssl req -newkey rsa:2048 -days 3650 -nodes \
    -keyout server-key.pem -out server-req.pem
openssl rsa -in server-key.pem -out server-key.pem
openssl x509 -req -in server-req.pem -days 3650 \
    -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 \
    -out server-cert.pem

Percona Operator 配置:

spec:
  pxc:
    sslSecretName: pxc-ssl
    sslInternalSecretName: pxc-ssl-internal
23 PXC 的异步从库(Async Slave)挂载

答案:

PXC 节点可作为传统异步复制的主库,挂载异步 Slave 实现跨区域灾备或只读扩展,通过 wsrep 的 log_slave_updates 和 GTID 实现平滑切换。

[分层展开]

架构:

+--------+     +--------+     +--------+
| PXC-1  | <-> | PXC-2  | <-> | PXC-3  |
|Master  |     |Master  |     |Master  |
+---+----+     +--------+     +--------+
    | 异步复制
    v
+--------+
| Async   |
| Slave   |
+--------+

配置步骤:

-- 1. 在 PXC 节点上启用 binlog(主库)
-- my.cnf
-- [mysqld]
-- log_bin = mysql-bin
-- log_slave_updates = ON
-- binlog_format = ROW
-- gtid_mode = ON
-- enforce_gtid_consistency = ON

-- 2. 创建复制用户
CREATE USER 'repl'@'%' IDENTIFIED BY 'repl_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

-- 3. 在 Slave 上配置复制
CHANGE MASTER TO
  MASTER_HOST = 'pxc-node-1',
  MASTER_USER = 'repl',
  MASTER_PASSWORD = 'repl_password',
  MASTER_AUTO_POSITION = 1;

START SLAVE;

-- 4. 验证
SHOW SLAVE STATUS\G

PXC 主库切换:当异步复制的主 PXC 节点故障时,Slave 通过 GTID 自动连接到另一 PXC 节点,确保复制连续性。

适用场景:

  • 跨数据中心灾备(远距离、高延迟不适合同步方案)
  • 报表/分析只读实例(与 OLTP 集群隔离)
  • 零停机迁移的过渡方案

注意事项:异步从库的数据一致性为最终一致性,延迟取决于网络和主库写入量。

24 PXC 的 wsrep_provider 参数详解

答案:

wsrep_provider_options 是 PXC 的核心配置项,控制 Galera Replication Plugin 的行为,涵盖通信、缓存、流控、认证和驱逐策略。

[分层展开]

核心参数分类:

通信参数(gcomm / gcs):

参数默认值说明
gcs.fc_limit16流控队列阈值,超过则暂停发送
gcs.fc_factor1.0动态流控灵敏度因子
gcs.max_packet_size64500最大网络包大小(bytes)
gcs.max_throttle0.005最大节流间隔(秒)

缓存参数(gcache):

参数默认值说明
gcache.size128Mgcache 环形缓冲区大小
gcache.page_size128M磁盘 page 文件大小
gcache.keep_pages_size0保留在内存中的 page 总量

驱逐与超时(evs):

参数默认值说明
evs.inactive_check_periodPT0.5S节点活跃检查间隔
evs.suspect_timeoutPT5S节点可疑超时(标记为 suspect)
evs.inactive_timeoutPT15S节点非活跃超时(驱逐)
evs.keepalive_periodPT1S心跳间隔

仲裁参数(pc):

参数默认值说明
pc.weight1节点仲裁权重
pc.ignore_sbfalse是否忽略脑裂
pc.ignore_quorumfalse是否忽略仲裁要求

生产环境推荐配置:

[mysqld]
wsrep_provider_options = "
  gcache.size=4G;
  gcache.page_size=256M;
  gcs.fc_limit=32;
  gcs.fc_factor=0.8;
  gcs.max_packet_size=64500;
  evs.inactive_check_period=PT1S;
  evs.suspect_timeout=PT10S;
  evs.inactive_timeout=PT30S;
  evs.keepalive_period=PT3S;
  pc.weight=1;
  gmcast.segment=1
"
25 PXC 的 K8s 升级策略(滚动升级 vs 全量替换)

答案:

Percona Operator 支持两种升级策略:Smart Update(类似滚动升级)和传统的全量替换重建;Smart Update 逐节点升级并利用 IST 恢复,避免 SST 重建,是生产环境推荐方式。

[分层展开]

升级策略对比:

维度Smart Update(滚动升级)全量替换
过程逐 Pod 升级,等待节点 Synced 后再升级下一个直接重建所有 Pod,并行 SST
数据同步优先 IST,减少数据拷贝每组 Pod 可能触发 SST
可用性全程可读写(至少保持 quorum)短暂不可用
耗时较长(逐节点迁回)较短(并行重建)
网络流量低(IST 增量数据)高(SST 全量快照)
风险低,可回滚中,数据丢失风险
适用 PXC 版本8.0.x 间小版本跨大版本(5.7 -> 8.0)

Operator 升级配置:

spec:
  crVersion: 1.15.0
  upgradeOptions:
    versionServiceEndpoint: https://check.percona.com
    apply: disabled              # disabled / recommended / latest / 8.0.35-27.1
    schedule: "0 4 * * *"        # 定时升级窗口

版本兼容性矩阵:

升级路径方式备注
PXC 8.0.32 -> 8.0.35Smart Update小版本,IST 可用
PXC 5.7 -> 8.0全量替换 / 迁移跨大版本,需 xtrabackup 兼容检查
Operator 1.13 -> 1.15Smart UpdateOperator 自身升级不影响数据面

升级检查清单:

# 1. 确认当前集群状态
kubectl get pxc -o yaml

# 2. 检查节点状态
kubectl exec -it cluster1-pxc-0 -- mysql -e "SHOW STATUS LIKE 'wsrep%'"

# 3. 确认备份可用(升级前必做备份)
kubectl get pxc-backup

# 4. 设置 apply 策略
# spec.upgradeOptions.apply = recommended

# 5. 监控升级过程
kubectl logs -f deployment/percona-xtradb-cluster-operator
kubectl get pods -w
26 PXC 的存储选型(Local PV vs Ceph RBD vs NFS)

答案:

PXC 对存储延迟极度敏感,Local PV 提供最低延迟和最高 IOPS,是生产环境首选;Ceph RBD 提供可移植性和动态供给;NFS 延迟高,不推荐用于 PXC 数据卷。

[分层展开]

维度Local PVCeph RBDNFS
延迟<1ms(本地磁盘)1-5ms(网络 + 副本)5-20ms(协议开销)
IOPS磁盘原生 IOPS受网络和副本数影响最低
数据持久性单副本,本地磁盘故障数据丢失多副本(3x),高持久性依赖 NFS 后端
Pod 可移植性绑死节点,无法漂移可漂移到任意节点可漂移到任意节点
动态供给(CSI)支持(LocalPV CSI)支持(RBD CSI)支持(NFS CSI)
SST 性能最优(本地 I/O)良好较差
运维复杂度低中(需维护 Ceph 集群)低
PXC 兼容性测试充分,官方推荐测试充分不推荐
备份需额外备份工具可利用 RBD 快照可利用存储快照

选型建议:

  • 单集群、高性能场景:Local PV + Operator 定期备份到 S3
  • 多云/混合云、需要 Pod 漂移:Ceph RBD
  • 开发测试环境:NFS(仅限非性能敏感场景)

Local PV 配置示例:

spec:
  pxc:
    volumeSpec:
      persistentVolumeClaim:
        storageClassName: local-ssd
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Gi

Ceph RBD 配置示例:

spec:
  pxc:
    volumeSpec:
      persistentVolumeClaim:
        storageClassName: ceph-rbd
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Gi
27 PXC 对 K8s PodDisruptionBudget 的配置

答案:

Percona Operator 自动为 PXC 创建 PodDisruptionBudget(PDB),确保在自愿性中断(节点维护、集群缩容)期间始终保留仲裁所需的节点数,防止集群进入 Non-Primary 状态。

[分层展开]

PDB 原理:

  • PDB 定义了同时不可用的最小或最大 Pod 数,K8s 调度器在驱逐 Pod 时尊重 PDB 约束
  • 自愿性中断受 PDB 约束(drain、Deployment 滚动更新),非自愿中断(节点宕机)不受约束

默认 PDB 配置:

# Operator 自动生成的 PDB
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: cluster1-pxc
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: percona-xtradb-cluster
      app.kubernetes.io/instance: cluster1

3 节点集群 PDB 分析:

maxUnavailable可容忍中断风险
1可安全驱逐 1 个 Pod驱逐期间若有节点同时故障,可能丢失 quorum
2可同时驱逐 2 个 Pod仅剩 1 节点,集群进入 Non-Primary
0不允许任何驱逐无法执行节点维护

5 节点集群 PDB:

spec:
  maxUnavailable: 2  # 可同时中断 2 个 Pod,仍保有 3 节点 quorum

节点维护操作流程:

# 1. 确认集群状态
kubectl exec cluster1-pxc-0 -- mysql -e "SHOW STATUS LIKE 'wsrep_cluster_size'"

# 2. 检查 PDB 状态
kubectl get pdb cluster1-pxc

# 3. 执行节点 drain(受 PDB 保护)
kubectl drain node-1 --ignore-daemonsets --delete-emptydir-data

# 4. 观察 Pod 驱逐过程
kubectl get pods -w

# 5. 维护完成后 uncordon 节点
kubectl uncordon node-1

注意事项:PDB 仅约束自愿性中断,不防止非自愿故障,因此 PDB 设置不能替代最小节点数设计和仲裁规划。

28 PXC 与 Vitess 的对比

答案:

PXC 是基于 Galera 的多主同步复制 MySQL 集群方案,面向强一致性和低延迟读写的 OLTP 场景;Vitess 是 MySQL 的水平分片中间件,面向超大规模数据集和高吞吐的互联网场景。

[分层展开]

维度PXCVitess
数据模型单一数据副本集,每个节点全量数据分片模型,每分片独立 MySQL 实例
扩展方式垂直扩展(读节点横向扩展)水平分片,数据按 shard key 分布
写入扩展受 Galera 认证限制,写入不线性扩展线性写入扩展,各分片独立写入
一致性强一致性(同步复制 + 认证)分片内强一致,跨分片最终一致
跨分片事务不支持(单集群内所有数据本地)支持有限的 2PC 跨分片事务
SQL 兼容性完整 MySQL SQL 支持有限(无 JOIN 跨分片、有限子查询等)
运维复杂度低-中(Galera 集群管理)高(Vttablet/Vtgate/topology 等多组件)
数据量上限TB 级(单节点存储上限)PB 级(水平分片无理论上限)
适用场景金融、交易、配置管理等强一致 OLTP社交媒体、IoT、日志等超大规模场景
节点拓扑感知Galera Segment 跨 DC 支持原生多 DC 拓扑感知路由
K8s 支持Percona Operator(成熟)Vitess Operator / Helm(成熟)

选择依据:

场景特征推荐方案
单数据集 < 5TB,需要完整 SQL 支持PXC
数据量 > 10TB,可接受分片限制Vitess
强一致性 + 低延迟PXC
极高写入吞吐 + 可接受最终一致Vitess
多活写入、无单点故障PXC
全球部署、超大规模用户Vitess
29 PXC 的容器化最佳实践

答案:

PXC 容器化部署需关注资源隔离、存储持久化、网络优化、配置管理和生命周期钩子,通过 Percona Operator 实现声明式管理,确保生产级可用性。

[分层展开]

1. 资源配置:

spec:
  pxc:
    resources:
      requests:
        memory: "4Gi"
        cpu: "2"
      limits:
        memory: "8Gi"
        cpu: "4"

2. 存储配置:

  • 使用 SSD 或 NVMe 存储类,禁止使用 NFS 或网络文件系统
  • PVC 大小预留 30% 余量用于 tmpdir 和 binlog

3. Pod 反亲和性:

spec:
  pxc:
    affinity:
      antiAffinityTopologyKey: kubernetes.io/hostname  # 每个物理节点最多 1 个 PXC Pod

4. 网络调优:

# sysctl 参数(通过 initContainer 设置)
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

5. 安全配置:

spec:
  pxc:
    # 非 root 运行
    runAsUser: 1001
    runAsGroup: 1001
    # 启用 SSL
    sslSecretName: pxc-ssl
    sslInternalSecretName: pxc-ssl-internal

6. 就绪与存活探针:

# Operator 自动配置的探针逻辑
# 就绪探针:wsrep_ready=ON AND wsrep_local_state=4
# 存活探针:mysqld 进程存活
# 启动探针:允许 SST 期间的较长启动时间

spec:
  pxc:
    readinessDelaySec: 15
    livenessDelaySec: 60

7. 备份验证:

spec:
  backup:
    schedule:
      - name: daily-backup
        schedule: "0 2 * * *"
        keep: 7
    # 定期验证备份可用性
    # 通过 restore job 验证

8. 监控集成:

spec:
  pmm:
    enabled: true
    image: percona/pmm-client:2
    serverHost: monitoring-service

禁止事项:

  • 禁止在同一个 K8s Node 上部署多个 PXC Pod(通过 PodAntiAffinity 实施)
  • 禁止使用 emptyDir 作为数据卷
  • 禁止未经备份验证直接升级 Operator 版本
  • 禁止在生产环境使用默认密码
30 PXC 的常见问题与故障排查

答案:

PXC 常见问题包括节点无法加入集群、SST 失败、流控频繁、认证冲突、gcache 溢出和集群 Non-Primary,通过 wsrep 状态变量和错误日志定位根因。

[分层展开]

问题一:节点无法加入集群(Joining 状态卡住)

-- 排查步骤
-- 1. 检查网络连通性
-- 2. 检查 wsrep_cluster_address 配置
-- 3. 检查 SST 用户权限
-- 4. 查看错误日志

SHOW STATUS LIKE 'wsrep_local_state_comment';
-- 长时间显示 Joining -> 检查 SST 日志

典型原因与解决:

现象根因解决方案
Joining 卡住SST 用户权限不足GRANT ALL ON . TO ‘sstuser’@’%’
Joining 卡住防火墙拦截端口 4444/4567/4568开放 Galera 所需端口
Joining 卡住Donor 节点 gcache 不足增大 gcache.size 或强制 SST
Joining 失败数据目录非空清空数据目录后重启

问题二:SST 失败

# 检查 SST 日志
grep -i sst /var/log/mysql/error.log

# 常见原因
# - xtrabackup 版本不匹配
# - Donor 磁盘空间不足
# - SST 用户认证失败

# 手动触发 SST
rm -f /var/lib/mysql/grastate.dat
systemctl restart mysql

问题三:频繁流控

-- 诊断
SHOW STATUS LIKE 'wsrep_flow_control%';
SHOW STATUS LIKE 'wsrep_local_recv_queue%';

-- 优化
SET GLOBAL wsrep_slave_threads = 8;

问题四:认证冲突(死锁错误 1213)

-- 监控冲突
SHOW STATUS LIKE 'wsrep_local_bf_aborts';
SHOW STATUS LIKE 'wsrep_local_cert_failures';

-- 应对
-- 1. 应用层实现重试逻辑
-- 2. 将热点数据写入路由至同一节点
-- 3. 排查是否有跨节点并发更新同一行

问题五:gcache 溢出导致 SST

-- 检查 gcache 使用率
-- gcache 溢出表现为 IST 不可用,节点回退至 SST

-- 增加 gcache 大小
-- wsrep_provider_options = "gcache.size=8G"

问题六:集群 Non-Primary

# 根因定位
# 1. 确认存活节点数
mysql -e "SHOW STATUS LIKE 'wsrep_cluster_size'"

# 2. 检查网络分区
# 3. 检查是否所有节点同时崩溃

# 恢复步骤
# 确认 safe_to_bootstrap 节点
cat /var/lib/mysql/grastate.dat
# 将 seqno 最高的节点设为 safe_to_bootstrap: 1

# Bootstrap 集群
mysqld --wsrep-new-cluster

# 其余节点正常启动
systemctl start mysql

问题七:PXC 所需端口

端口协议用途
3306TCPMySQL 客户端连接
4444TCPSST 数据传输
4567TCP/UDPGalera 组通信(gcomm)
4568TCPIST 增量数据传输

故障排查工具速查:

-- 综合健康检查
SHOW GLOBAL STATUS LIKE 'wsrep%';

-- 集群基本信息
SELECT * FROM performance_schema.replication_group_members;  -- Group Replication
-- PXC 无对应表,使用 SHOW STATUS

-- 检查 InnoDB 状态(冲突检测日志)
SHOW ENGINE INNODB STATUS\G