Vitess 面试题

答案：

Vitess 是 CNCF 毕业项目，为 MySQL 提供水平扩展能力的数据库集群系统，由 YouTube 于 2010 年创建并开源。核心架构由以下组件构成：

架构工作流

Client -> VTGate（SQL 解析与路由） -> VTTablet（查询执行） -> MySQL（数据存储） 所有组件通过 TopoServer 发现彼此状态，VTCtld 作为控制面执行管理操作。

答案：

Vitess 使用 VSchema 定义逻辑到物理的映射关系，将用户可见的 keyspace 和 table 映射到底层分片。

VSchema 核心元素

分片策略

{
  "sharded": true,
  "vindexes": {
    "hash": {
      "type": "hash"
    }
  },
  "tables": {
    "user": {
      "column_vindexes": [
        {
          "column": "user_id",
          "name": "hash"
        }
      ]
    }
  }
}

分片选择流程

VTGate 收到 SQL 后解析 WHERE 条件，提取分片键值，通过 VIndex 映射确定目标分片。等值查询精确定位单个分片，范围查询覆盖多个分片，不带分片键的查询触发 Scatter 全分片广播。

答案：

VTGate 作为集群的入口代理，承载查询解析、路由计划和连接管理三重职责。

查询路由流程

1. 接收客户端 MySQL 协议连接，解析 SQL 语句
2. 从 TopoServer 获取 VSchema 和 Tablet 拓扑信息
3. 生成查询计划：定位分片键并映射到目标分片
4. 将查询转发至目标 VTTablet，并发执行多分片查询
5. 聚合各分片结果（排序、合并、去重、分页），返回客户端

连接池机制

查询计划类型

• Single Shard：精确定位单分片，直接转发
• Multi Shard Scatter：广播到所有分片，聚合结果
• Subquery：将复杂查询分解为子查询分别执行

答案：

VTTablet 是每个 MySQL 实例前的代理进程，负责查询代理、健康检查和状态上报。Tablet 按照在副本集中的角色分为三种类型：

Tablet 状态机

INIT -> SHUTTING_DOWN -> RESTORE -> NOT_SERVING -> SERVING -> SHUTTING_DOWN SERVING 状态下 Tablet 接收查询流量，NOT_SERVING 表示健康但不可服务。

Tablet 关键职责

• 查询执行：接收 gRPC 请求并转换为 MySQL 查询
• 连接池管理：维护到 MySQL 的连接池，按事务 ID 绑定连接
• 健康检查：定期执行 select 1 等健康查询，上报 TopoServer
• 备份恢复：执行 mysqlctl 备份命令，从备份恢复数据
• 查询重放与扼制：事务期间错误自动重试，慢查询扼制

答案：

TopoServer 是 Vitess 的分布式元数据存储，记录集群拓扑信息，需满足强一致性和高可用要求。

支持的后端

元数据内容

• 集群全局信息：Cell 定义、Keyspace 列表
• Keyspace 与 Shard 信息：分片范围、Tablet 列表
• Schema 版本：当前活跃的 Schema 定义
• VReplication 工作流状态：数据迁移位置和位点

选型考量

Kubernetes 环境默认使用 etcd。生产部署采用至少 3 节点的 etcd 集群，使用 SSL 加密通信。使用 vtctl TopoCat 命令检查和备份拓扑数据。Vitess 支持 vtctldclient 直接操作拓扑结构。

答案：

VReplication 是 Vitess 的核心数据复制引擎，基于 MySQL binlog 实现实时数据同步，支撑在线 Resharding 和物化视图。

VReplication 核心概念

在线 Resharding 流程

1. 创建新的目标分片，部署 Tablet 并初始化 Schema
2. 创建 VReplication 工作流：vtctldclient MoveTables Create
3. CopyPhase：将源分片数据全量拷贝到目标分片
4. CatchupPhase：追赶 CopyPhase 期间产生的增量数据
5. VDiff：校验源端与目标端数据一致性
6. SwitchWrites：切换写入流量到新分片
7. SwitchReads：切换读取流量到新分片
8. DropSources：确认无误后删除源表数据

常用操作命令

# 创建 Resharding 工作流
vtctldclient MoveTables Create --source commerce --tables 'customer,corder' \
  CreateDefaultWorkflow customer

# 切换写入
vtctldclient MoveTables SwitchTraffic --tablet_types=primary customer

# 切换读取
vtctldclient MoveTables SwitchTraffic --tablet_types=replica,rdonly customer

# 完成并清理
vtctldclient MoveTables Complete customer

关键特性

在线切换期间写入仅短暂中断（SwitchWrites 阶段网关瞬断），整个过程对应用透明，可随时取消并回滚。

答案：

VDiff 是 Vitess 内置的数据一致性校验工具，在 VReplication 工作流中逐表比较源端与目标端数据。

工作方式

1. 在源端和目标端同时启动 VDiff 工作流
2. 对每张表进行分块校验：将主键范围切分为多个 Chunk
3. 每个 Chunk 计算源端和目标端的行校验和（checksum）
4. 校验和不一致的 Chunk 执行逐行精确比较
5. 汇总差异报告

VDiff 命令

# 对工作流执行 VDiff
vtctldclient VDiff --v2 customer.commerce2customer

# 查看 VDiff 进度
vtctldclient VDiff --v2 show last

# 停止正在进行的 VDiff
vtctldclient VDiff --v2 stop customer.commerce2customer

关键配置

最佳实践

在 SwitchWrites 之前执行 VDiff 验证数据一致性。使用 RDONLY Tablet 避免影响线上读写。对于大表，VDiff 可能需要数小时，分阶段执行。

答案：

Vitess 提供两种 Online DDL 方案：原生 vitess 策略（基于 VReplication）和集成 gh-ost / pt-osc。

三种 DDL 策略对比

Vitess Online DDL 工作流

1. 客户端通过 VTGate 提交 ALTER TABLE
2. VTGate 转换为 Online DDL 请求，创建 Schema 迁移任务
3. Vitess 创建 shadow table，启动 VReplication 流同步数据
4. 数据同步完成后执行 cut-over（短暂锁定切换表名）
5. 删除旧表，迁移完成

-- 使用 Vitess 原生策略的 Online DDL
ALTER /*vt+ uuid=xxx */ TABLE user ADD COLUMN email VARCHAR(255);

-- 指定 gh-ost 策略
SET @@ddl_strategy='gh-ost';
ALTER TABLE user ADD COLUMN email VARCHAR(255);

Declarative DDL

-- 声明目标 Schema，Vitess 自动计算差异并执行
SET @@ddl_strategy='vitess';
CREATE TABLE IF NOT EXISTS user (
  id BIGINT PRIMARY KEY,
  name VARCHAR(100)
);

注意事项

Online DDL 期间表必须有主键。gh-ost 不支持外键约束。大表变更关注磁盘使用量（shadow table 占用额外空间）。生产环境建议先审查 Migration 计划再执行。

答案：

Vitess 将 SQL 解析为内部查询计划（PlannedQuery），VExplain 提供查询计划的可视化和分析能力。

查询计划类型

VExplain 命令

-- 查看查询计划（不执行）
VEXPLAIN QUERIES SELECT * FROM user WHERE user_id = 1;

-- 查看执行计划（实际执行并分析）
VEXPLAIN ALL SELECT * FROM user WHERE user_id = 1;

-- 以 JSON 格式输出
VEXPLAIN FORMAT=JSON SELECT * FROM user WHERE user_id > 100;

VExplain 输出解读

VExplain 显示每个分片的执行路径，包括：

• Operator Tree：查询算子树形结构
• Shard Queries：下发到各分片的实际 SQL
• Tablet Calls：涉及的 Tablet 数量
• Rows Returned：各分片返回行数

执行计划优化要点

避免 Scatter 查询，确保 WHERE 条件包含分片键。减少不必要的跨分片 Join 和 Subquery。使用 straight_join 控制的 Join 顺序。利用 VExplain 定位性能瓶颈。

答案：

Vitess 兼容大部分 MySQL 语法，但存在架构限制导致的差异。

不支持的特性

部分支持的 SQL

兼容性检测

使用 Vitess 的 compatibility 测试套件验证 SQL 兼容性。plan_test.go 确保查询计划的确定性和可预测性。

最佳实践

采用 Vitess 支持的 SQL 子集设计数据访问层。避免依赖 MySQL 特有扩展。使用 VExplain 验证查询计划。

答案：

Vitess 实现两阶段提交协议支持跨分片写事务。

事务模型

2PC 工作流程

1. Prepare Phase：协调者（VTGate）向所有参与者（VTTablet）发送 Prepare 请求
2. 各参与者将事务写入 redo log（_vt.redo_state 表），返回 Prepare ACK
3. Commit Phase：协调者收到全部 Prepare ACK 后发送 Commit 请求
4. 各参与者提交本地事务，写入 commit log
5. 协调者清理 redo log 记录

故障恢复机制

• Prepare 阶段失败：协调者发送 Rollback
• Commit 阶段部分失败：依靠 _vt.redo_state 和 _vt.dt_state 表恢复
• VTCtld 中的 DT（Distributed Transaction）逻辑负责解析残留事务

配置与优化

# 启用 2PC
vtgate:
  twopc_enable: true
  twopc_coordinator_address: "localhost:2379"
  twopc_abandon_age: 3600  # 1 小时后放弃悬挂事务

限制

2PC 写性能约为单分片事务的 3-5 倍延迟。悬挂事务（Coordinator 宕机）需手工介入。建议优先设计分片键避免跨分片事务。

答案：

Vitess 提供三种 Kubernetes 部署方式：Vitess Operator（官方推荐）、Helm Chart 和裸 YAML。

部署方式对比

Vitess Operator 核心 CRD

架构配合

apiVersion: planetscale.com/v2
kind: VitessCluster
metadata:
  name: commerce
spec:
  images:
    vitess: vitess/lite:v17.0.0
  cells:
  - name: zone1
    gateway:
      resources:
        requests:
          memory: 1Gi
          cpu: 500m
  keyspaces:
  - name: commerce
    partitionings:
    - equal:
        parts: 2
        shardTemplate:
          tabletPools:
          - cell: zone1
            type: replica
            replicas: 2
            dataVolumeClaimTemplate:
              accessModes: ["ReadWriteOnce"]
              resources:
                requests:
                  storage: 100Gi

拓扑配置

Vitess Operator 支持跨 Availability Zone 部署，通过 PodAntiAffinity 确保副本分散，利用 TopologySpreadConstraints 提升容灾能力。

答案：

Vitess 提供内置备份和恢复机制，通过 mysqlctl 工具执行。

备份类型

备份存储后端

S3、GCS、Azure Blob、本地文件系统、NFS

备份命令

# 执行全量备份
vtctldclient BackupShard commerce/0

# 从备份恢复创建 Tablet
vtctldclient RestoreFromBackup zone1-100

备份策略配置

# Vitess Operator 自动备份配置
backup:
  engine: xtrabackup
  location:
    s3:
      endpoint: s3.amazonaws.com
      bucket: vitess-backups
      root: commerce
  schedule:
    cron: "0 2 * * *"  # 每日凌晨 2 点
    retention: 168h     # 保留 7 天
  concurrency: 2

Restore 流程

1. 新 Tablet 启动后检测自身状态
2. 从 TopoServer 查找最近备份
3. 下载备份文件并解压
4. 应用 binlog 到指定位点
5. 启动 MySQL 并加入副本集

生产注意事项

定期验证备份可恢复性。备份期间使用 RDONLY Tablet 避免影响线上流量。多区域部署时各区域保留独立备份。

答案：

Vitess 通过 VTOrc、自动故障检测和 Tablet 冗余实现高可用。

高可用组件

故障转移流程

1. VTOrc 持续监控 PRIMARY Tablet 健康状态
2. 检测到 PRIMARY 不可达（连续检测失败超过阈值）
3. VTOrc 验证拓扑一致性，分析候选 REPLICA
4. 选择最先进的 REPLICA（最大 GTID 位点）
5. 执行 DemotePrimary 降级旧主
6. 执行 PromoteReplica 提升新主
7. 更新 TopoServer，通知 VTGate 路由变更

PlannedReparentShard

计划内主从切换，用于维护操作和版本升级。

# 计划内切换主从
vtctldclient PlannedReparentShard commerce/0 --new-primary zone1-101

# 紧急故障转移
vtctldclient EmergencyReparentShard commerce/0 --new-primary zone1-101

配置

vtorc:
  recovery_poll_interval: 5s
  reasonable_replication_lag: 10s
  reasonable_primary_downtime: 30s
  prevent_cross_cell_primary_failover: true
  lock_shard_timeout: 30s

故障转移影响

切换期间写入短暂阻塞（秒级）。应用层需配置重试机制。使用 GTID 确保数据一致性。

答案：

Vitess Operator 是 Kubernetes 原生控制器，通过声明式 CRD 管理 Vitess 集群生命周期。

核心能力

主要 CRD

apiVersion: planetscale.com/v2
kind: VitessCluster
spec:
  cells: []         # Cell 定义（计算+网关资源）
  keyspaces: []     # Keyspace 定义（分片+Tablet 配置）
  vitessDashboard: {} # Vitess 内置 Dashboard
  topologyReconciliation:
    pruneOrphans: true

生命周期管理

1. kubectl apply 提交 CRD YAML
2. Operator 解析 CRD 并生成 StatefulSet/Deployment/Service 资源
3. 监控 Pod 状态，处理滚动更新和故障恢复
4. 协调 TopoServer 元数据与 K8s 实际状态一致

版本升级

修改 CRD 中 images.vitess 版本号，Operator 按 Tablet 类型分批滚动更新： RDONLY -> REPLICA -> PRIMARY，每批之间等待健康检查通过。

常见配置路径

# 集群状态
kubectl get vitessclusters
kubectl get vitessshards

# 操作集群
kubectl exec -it vtctld-0 -- vtctldclient GetKeyspaces

答案：

Vitess 内置 Prometheus metrics 端点，暴露丰富的性能、健康、延迟和资源指标。

关键指标分类

Prometheus 配置

scrape_configs:
  - job_name: 'vtgate'
    static_configs:
      - targets: ['vtgate-0:15000', 'vtgate-1:15000']

  - job_name: 'vttablet'
    static_configs:
      - targets: ['vttablet-0:15000', 'vttablet-1:15000']

告警规则示例

groups:
  - name: vitess
    rules:
      - alert: HighQueryErrorRate
        expr: rate(vtgate_error_counts[5m]) / rate(vtgate_query_counts[5m]) > 0.01
        for: 5m
        labels:
          severity: critical

      - alert: VReplicationLagHigh
        expr: vreplication_lag_seconds > 300
        for: 10m

      - alert: TabletNotServing
        expr: vttablet_tablet_type == 0
        for: 2m

Grafana 仪表盘

Vitess 官方提供 Grafana Dashboard JSON 模板，覆盖 VTGate Query、VTTablet Performance、VReplication Status、MySQL Metrics 等视图。

答案：

Vitess 在三个层级管理数据库连接池：客户端到 VTGate、VTGate 到 VTTablet、VTTablet 到 MySQL。

三级连接池架构

VTTablet 连接池配置

vttablet:
  queryserver-config-pool-size: 16
  queryserver-config-stream-pool-size: 200
  queryserver-config-transaction-cap: 20
  queryserver-config-max-result-size: 100000
  queryserver-config-query-timeout: 30s

事务连接管理

事务开始时 VTTablet 分配专用 MySQL 连接，事务内所有操作复用同一连接，事务提交或回滚后释放。避免连接泄漏：设置 queryserver-config-transaction-timeout 超时自动回滚。

连接耗尽防护

• 配置最大连接数限制
• 连接池空闲超时回收
• 慢查询杀灭机制（queryserver-config-query-timeout）
• 热表保护：并发查询过多时触发限流

连接池监控

答案：

Vitess 通过 VReplication Materialize 实现物化视图，通过 VSchema Lookup VIndex 实现分片定位缓存。

Materialize（物化视图）

基于 VReplication 将源表的数据实时同步到物化表，支持数据转换和聚合。

-- 创建物化视图
CREATE MATERIALIZED VIEW user_order_summary AS
SELECT user_id, COUNT(*) as order_count, SUM(amount) as total_amount
FROM corder
GROUP BY user_id;

物化视图的工作流程：

1. CopyPhase：全量回填已有数据
2. CatchupPhase：追赶增量数据
3. 进入稳态持续同步

应用场景：汇总表、宽表加速查询、跨分片 Join 替代方案、实时报表。

Lookup VIndex 缓存

Lookup VIndex 维护分片键到分片的映射表，支持一致性哈希无法覆盖的非分片键查询。VTGate 查询 Lookup VIndex 时会将映射关系缓存在本地，减少对 Lookup 表的查询压力。

{
  "vindexes": {
    "user_index": {
      "type": "lookup",
      "params": {
        "table": "user_keyspace_id_map",
        "from": "user_id",
        "to": "keyspace_id"
      },
      "owner": "user"
    }
  }
}

一致性 Lookup

Consistent Lookup VIndex 使用分布式锁确保 Lookup 表和主表数据一致，使用 2PC 事务保证写入的原子性。

答案：

Vitess 通过 Resharding 实现在线添加分片，无需停机。

扩展步骤

1. 创建新分片 Schema：在新 Tablet 上创建空数据库结构

vtctldclient ApplySchema --sql="CREATE TABLE user (...)" commerce

2. 创建分片：使用 Operator 或 vtctldclient 创建新分片

vtctldclient CreateShard commerce/80-

3. 创建 Resharding 工作流：将部分数据迁移到新分片

vtctldclient Reshard Create --source_shards '0' --target_shards '-80,80-' \
  Create merchant.reshard_workflow

4. 监控进度：等待 CopyPhase 和 CatchupPhase 完成

vtctldclient Workflow merchant.reshard_workflow show

5. 执行 VDiff：校验数据一致性

vtctldclient VDiff --v2 merchant.reshard_workflow

6. 切换流量：先写后读

vtctldclient Reshard SwitchTraffic --tablet_types=primary merchant.reshard_workflow
vtctldclient Reshard SwitchTraffic --tablet_types=replica,rdonly merchant.reshard_workflow

7. 完成：移除源分片旧数据

vtctldclient Reshard Complete merchant.reshard_workflow

容量规划

答案：

Vitess 通过 Cell 抽象支持多数据中心部署，每个 Cell 包含完整的 VTGate 和 Tablet 集合。

Cell 模型

多区域架构

Region-A (Cell-1)              Region-B (Cell-2)
  VTGate------------------+       VTGate------------------+
  VTTablet (PRIMARY)      |       VTTablet (REPLICA)      |
  MySQL                   |       MySQL                    |
                          |                                |
              Global TopoServer (etcd x3)

跨 Cell 复制

每个 Cell 的 PRIMARY 位于主区域，其他区域部署 REPLICA。通过跨区域 binlog 复制保持数据同步。

流量路由策略

• 读写请求默认路由到本地 Cell
• 写入通过本地 VTGate 代理到 PRIMARY Cell
• VTGate 配置 discovery_low_replication_lag 优先选择低延迟副本

灾难恢复

# 跨区域故障转移配置
vtorc:
  prevent_cross_cell_primary_failover: false  # 允许跨 Cell 选主

跨 Cell 主从切换通过 VTOrc 自动执行或手动 EmergencyReparentShard 触发。

注意事项

跨区域网络延迟影响写入性能。TopoServer 必须有跨区域冗余节点。备份数据在各区域独立存储。

答案：

Vitess 的多层健康检测机制确保异常 Tablet 及时从服务池中剔除，恢复后自动重新加入。

健康检测层级

健康检查内容

• Liveness Check：MySQL 是否存活（select 1）
• Replication Check：复制线程是否运行、延迟是否超阈值
• Schema Check：Schema 版本是否与 VSchema 一致
• Disk Check：磁盘使用率是否超过阈值

检测到异常后的行为

修复机制

• 自动恢复：MySQL 重启后 VTTablet 自动恢复 SERVING
• 重新克隆：严重数据损坏时从备份恢复或从主库重新克隆
• 滚动修复：Operator 分批重建异常 Tablet

答案：

Vitess 在 VTGate 层提供认证和 TLS 加密，MySQL 层保持原有权限体系。

认证机制

Static Auth 配置

{
  "user_data": [
    {
      "name": "app_user",
      "password": "app_password",
      "target_tablet_type": "REPLICA"
    }
  ]
}

vtgate --mysql_auth_server_impl=static --mysql_auth_server_static_file=auth.json

TLS 配置

vtgate \
  --mysql_server_ssl_cert=/certs/server-cert.pem \
  --mysql_server_ssl_key=/certs/server-key.pem \
  --mysql_server_ssl_ca=/certs/ca-cert.pem

MySQL 权限管理

Vitess 透传 MySQL 原生权限控制。通过 VTGate 执行 CREATE USER、GRANT 等 SQL 管理用户权限。

-- 通过 VTGate 创建只读用户
CREATE USER 'reader'@'%' IDENTIFIED BY 'password';
GRANT SELECT ON commerce.* TO 'reader'@'%';

安全最佳实践

强制 TLS 加密所有组件间通信。使用最小权限原则分配数据库用户。避免通过 VTGate 暴露 root 账户。定期轮换证书和密码。

答案：

Vitess 在原生 MySQL 之上添加了分布式抽象层，带来架构差异和功能取舍。

关键差异

兼容性设计

• 支持标准 MySQL 协议连接（任何 MySQL 客户端可连接 VTGate）
• 支持 PREPARE / EXECUTE 预处理语句
• 支持 JDBC/ODBC 标准驱动
• 支持 ORM 框架（Hibernate/MyBatis/GORM 等）

迁移考量

评估现有应用的 SQL 兼容性。重构存储过程和触发器。设计合理的分片键和 VSchema。做好连接池配置适配。

答案：

Vitess 与 ProxySQL、MySQL Router 同为 MySQL 代理，但定位和功能有显著差异。

功能对比

选型指南

答案：

Vitess 的性能优化涉及 SQL 设计、分片策略、连接配置和资源规划四个维度。

查询优化

连接配置优化

vttablet:
  # 连接池
  queryserver-config-pool-size: 16         # 连接池大小
  queryserver-config-stream-pool-size: 200 # 流式查询连接池

  # 事务
  queryserver-config-transaction-cap: 20   # 并发事务上限
  queryserver-config-tx-timeout: 30s       # 事务超时

vtgate:
  # 缓存
  gateway_initial_tablet_timeout: 30s
  discovery_low_replication_lag: 2s        # 低延迟副本阈值
  enable_buffer: true
  buffer_size: 10                          # 故障时缓冲查询

MySQL 参数优化

• innodb_buffer_pool_size：物理内存的 70-80%
• innodb_log_file_size：1-2GB（大写入量场景）
• innodb_flush_log_at_trx_commit：1（安全）或 2（性能）
• sync_binlog：1（安全）或 0（性能）

资源规划

答案：

Vitess 提供 Sequence 表机制，在分布式环境下生成全局唯一递增 ID。

Sequence 表定义

-- 创建 Sequence 表
CREATE TABLE user_seq (
  id BIGINT,
  next_id BIGINT,
  cache BIGINT,
  PRIMARY KEY(id)
) COMMENT 'vitess_sequence';

-- 插入 Sequence 元数据
INSERT INTO user_seq (id, next_id, cache) VALUES (0, 1000, 100);

VSchema 配置

{
  "tables": {
    "user_seq": {
      "type": "sequence"
    },
    "user": {
      "column_vindexes": [
        {
          "column": "id",
          "name": "hash"
        }
      ],
      "auto_increment": {
        "column": "id",
        "sequence": "user_seq"
      }
    }
  }
}

Sequence 工作原理

1. 应用插入时不指定 ID，VGtgte 检测到 auto_increment 表
2. VTGate 向 Sequence 表请求一段 ID 范围（cache 个 ID）
3. 本地缓存 ID 段，分配给插入请求
4. 缓存耗尽后重新请求下一段

特性与限制

• 全局唯一但非严格连续（缓存丢失会导致 ID 段跳跃）
• 支持自定义 cache 大小平衡性能与连续性
• 支持多 Sequence 表（不同业务使用不同序列）
• 不支持跨 Sequence 的全局有序性

性能

缓存大小影响 Sequence 性能。cache=1000 时，每 1000 次插入仅需一次 Sequence 表访问。

答案：

VReplication 的数据同步分为 CopyPhase、CatchupPhase 和 RunningPhase 三个阶段。

CopyPhase（全量拷贝）

目标端通过 SELECT 查询源端数据并分批插入。使用 Chunked Copy 避免大表一次性加载，默认每批 10000 行。此阶段源端写入正常进行。

# CopyPhase 配置
vttablet:
  vreplication_copy_phase_duration: 1h
  vreplication_copy_phase_max_innodb_history_list_length: 1000000
  vreplication_copy_phase_max_mysql_replication_lag: 43200

CatchupPhase（增量追赶）

CopyPhase 期间源端产生的增量数据通过 VStream binlog 追赶。此阶段 VReplication lag 持续下降，直到趋近于零。

RunningPhase（稳态同步）

增量完全追上后进入稳态。VReplication lag 保持在秒级。此阶段数据持续实时同步，SwitchTraffic 可在此阶段安全执行。

阶段监控

-- 查看 VReplication 状态
SELECT * FROM _vt.vreplication;

-- 查看延迟
SELECT
  id,
  workflow,
  db_name,
  pos,
  time_updated,
  message,
  TIMESTAMPDIFF(SECOND, time_updated, NOW()) AS lag_seconds
FROM _vt.vreplication;

故障处理

CopyPhase 中断：从断点续传。CatchupPhase 中断：从最后消费的 GTID 恢复。RunningPhase 长时间延迟：检查目标端写入能力或网络状况。

答案：

Vitess 生产的常见故障类型及排查路径。

VTGate 查询失败

VReplication 延迟过大

# 查看工作流状态
vtctldclient Workflow customer.commerce2customer show

# 查看 VStream 状态
SELECT * FROM _vt.vreplication;

# 检查 binlog 是否正常
SHOW BINARY LOGS;
SHOW BINLOG EVENTS IN 'binlog.000001' LIMIT 10;

常见原因：目标端写入性能不足、网络带宽瓶颈、binlog 格式不符合要求（需要 ROW 格式）。

Tablet 健康检查失败

# 查看 Tablet 日志
kubectl logs vttablet-zone1-100 -c vttablet

# 手动健康检查
mysql -h tablet-host -e "SELECT 1"

# 检查磁盘
df -h /vt/vtdataroot

TopoServer 连接异常

# 列出拓扑内容
vtctldclient --server=localhost:15999 GetKeyspaces

# 检查 etcd 集群健康
etcdctl endpoint health
etcdctl endpoint status

2PC 悬挂事务

-- 查找残留事务
SELECT * FROM _vt.dt_state;

-- 手动清理超时悬挂事务
-- 通过 vtctldclient ResolveTransaction 清理

答案：

Vitess 对 SQL 的支持分为完全支持、部分支持和不支持三类。

完全支持的 SQL

SELECT、INSERT、UPDATE、DELETE、CREATE TABLE、ALTER TABLE（Online DDL）、DROP TABLE、TRUNCATE、CREATE INDEX、DROP INDEX、USE、SHOW DATABASES、SHOW TABLES、SET、BEGIN/COMMIT/ROLLBACK、PREPARE/EXECUTE/DEALLOCATE

LIMIT/OFFSET 处理机制

-- 客户端查询
SELECT * FROM user ORDER BY id LIMIT 10 OFFSET 20;

-- VTGate 下发（各分片获取 Offset + Limit 共 30 条）
SELECT * FROM user ORDER BY id LIMIT 30;

-- VTGate 聚合后截取 20-30

聚合函数处理

简单聚合（COUNT/SUM/AVG）下发到分片后 VTGate 二次聚合。但对于 AVG 等非可合并函数，VTGate 分别求 SUM 和 COUNT 再计算。DISTINCT 聚合在 VTGate 层做最终去重。

Join 处理策略

性能影响的 SQL 模式

• SELECT * 返回所有列，增加网络传输
• 大 OFFSET 分页效率低，推荐游标分页
• OR 条件可能导致 Scatter 查询
• 函数包裹分片键（如 WHERE DATE(created_at) = '2024-01-01'）无法利用分片路由

答案：

Vitess 生产部署的成熟实践方案。

架构设计

分片设计

• 单分片数据量控制 500GB 以内
• 初始分片数预留 2-4 倍扩展空间（预分片）
• 选择低基数、均匀分布的分片键
• 避免热点分片：使用 Hash VIndex 而非 Range

安全配置

# TLS 全部加密
vtgate \
  --mysql_server_ssl_cert=/certs/server-cert.pem \
  --mysql_server_ssl_key=/certs/server-key.pem \
  --mysql_server_ssl_ca=/certs/ca-cert.pem

# 静态认证
vtgate --mysql_auth_server_impl=static \
  --mysql_auth_server_static_file=/etc/vitess/auth.json

备份策略

监控指标准则

• VTGate 查询延迟 P99 < 100ms
• VReplication Lag < 5s
• MySQL Replication Lag < 2s
• Tablet 连接池使用率 < 80%
• 磁盘使用率 < 80%

应急预案

变更管理

Schema 变更统一通过 Online DDL。Resharding 在低峰期执行，分批切换流量。所有管理操作通过 vtctldclient 执行并记录审计日志。使用 Vitess Operator 的滚动更新策略，按 RDONLY -> REPLICA -> PRIMARY 顺序升级。

容量规划

每季度评估数据增长趋势，预留 30% 存储和计算余量。监控每个分片的 QPS 趋势，在当前容量达到 70% 前启动 Resharding 增加分片。