印刻数据库

外观

MariaDB 运维规范 ​

数据库运维是确保数据库系统稳定运行、高性能和高可用的关键环节。一个完善的运维规范能够帮助运维团队高效协作，减少人为错误，提高系统可靠性。

日常运维流程 ​

1. 日常巡检 ​

每日巡检 ​

  • 系统层面：

    • 检查服务器 CPU、内存、磁盘 I/O 使用率
    • 检查磁盘空间，确保有足够的剩余空间
    • 检查系统日志，查看是否有异常信息
    • 检查网络连接状态

  • 数据库层面：

    • 检查数据库进程是否正常运行
    • 检查连接数和线程数
    • 检查慢查询日志
    • 检查主从复制状态（如果是主从架构）
    • 检查 Galera Cluster 状态（如果是 Galera 架构）
    • 检查数据库错误日志

  • 自动化巡检：

    • 使用脚本自动化收集巡检数据
    • 生成巡检报告
    • 设置巡检告警

  • 示例脚本：

bash
#!/bin/bash
# 简单的 MariaDB 每日巡检脚本

date

# 检查数据库进程
if pgrep -x "mysqld" > /dev/null; then
    echo "✓ MariaDB 进程运行正常"
else
    echo "✗ MariaDB 进程未运行"
fi

# 检查连接数
conn_count=$(mysql -u root -p"password" -e "SHOW GLOBAL STATUS LIKE 'Threads_connected';" | grep Threads_connected | awk '{print $2}')
echo "当前连接数: $conn_count"

# 检查慢查询
slow_queries=$(mysql -u root -p"password" -e "SHOW GLOBAL STATUS LIKE 'Slow_queries';" | grep Slow_queries | awk '{print $2}')
echo "慢查询数量: $slow_queries"

# 检查主从复制状态
if mysql -u root -p"password" -e "SHOW SLAVE STATUS\G" | grep -q "Slave_IO_Running: Yes" && mysql -u root -p"password" -e "SHOW SLAVE STATUS\G" | grep -q "Slave_SQL_Running: Yes"; then
    echo "✓ 主从复制状态正常"
    delay=$(mysql -u root -p"password" -e "SHOW SLAVE STATUS\G" | grep Seconds_Behind_Master | awk '{print $2}')
    echo "复制延迟: $delay 秒"
else
    echo "✗ 主从复制状态异常"
fi

# 检查磁盘空间
disk_usage=$(df -h / | grep / | awk '{print $5}')
echo "根目录磁盘使用率: $disk_usage"

echo "-----------------------------------"

每周/每月巡检 ​

  • 深度性能分析：

    • 分析慢查询日志，优化查询语句
    • 检查索引使用情况，删除无用索引
    • 分析表碎片，优化表结构
    • 检查数据库参数配置，进行必要的调整

  • 安全审计：

    • 检查用户权限，回收不必要的权限
    • 检查数据库安全配置
    • 检查审计日志

  • 备份验证：

    • 定期恢复备份，验证备份的可用性
    • 检查备份策略的有效性

  • 容量规划：

    • 分析数据增长趋势
    • 预测未来容量需求
    • 制定扩容计划

2. 监控与告警 ​

监控指标 ​

  • 系统指标：

    • CPU 使用率
    • 内存使用率
    • 磁盘 I/O 使用率
    • 磁盘空间
    • 网络流量

  • 数据库指标：

    • 连接数（Threads_connected, Max_used_connections）
    • 查询性能（Queries, Questions, Slow_queries）
    • 缓冲池使用情况（Innodb_buffer_pool_hit_rate）
    • 锁等待情况（Innodb_row_lock_waits, Innodb_lock_wait_timeout）
    • 事务情况（Com_commit, Com_rollback, Innodb_deadlocks）
    • 复制状态（Seconds_Behind_Master, Slave_IO_Running, Slave_SQL_Running）
    • Galera Cluster 状态（wsrep_cluster_status, wsrep_local_state_comment, wsrep_flow_control_paused）

监控工具 ​

  • 系统监控：

    • Prometheus + Grafana
    • Zabbix
    • Nagios

  • 数据库监控：

    • MariaDB Enterprise Monitor
    • Percona Monitoring and Management (PMM)
    • MySQL Enterprise Monitor
    • 自研监控系统

告警策略 ​

  • 告警分级：

    • P0：严重故障，影响核心业务，需立即处理
    • P1：重要故障，影响部分业务，需尽快处理
    • P2：一般故障，不影响业务，需计划处理
    • P3：警告信息，需关注

  • 告警渠道：

    • 邮件
    • 短信
    • 即时通讯工具（如钉钉、微信、Slack）
    • 电话（仅 P0 级别）

  • 告警阈值设置：

    • 根据业务需求和历史数据设置合理的告警阈值
    • 定期调整告警阈值，避免误报和漏报

3. 备份与恢复 ​

备份策略 ​

  • 3-2-1 备份原则：

    • 3 份备份副本
    • 2 种不同的存储介质
    • 1 份异地备份

  • 备份类型：

    • 全量备份：定期执行（如每日、每周）
    • 增量备份：在全量备份之间执行（如每小时）
    • 日志备份：实时备份二进制日志

  • 备份工具：

    • mysqldump：适用于中小数据量
    • mariabackup：适用于大数据量，支持热备份
    • mysqlpump：多线程备份工具（MariaDB 10.1+）

  • 备份示例：

bash
#!/bin/bash
# MariaDB 全量备份脚本

BACKUP_DIR="/backup/mariadb/full"
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="$BACKUP_DIR/backup_$DATE.tar.gz"

echo "开始执行全量备份: $DATE"

# 创建备份目录
mkdir -p $BACKUP_DIR

# 使用 mariabackup 执行全量备份
mariabackup --backup --target-dir=$BACKUP_DIR/$DATE --user=backup --password=backup_password

# 检查备份是否成功
if [ $? -eq 0 ]; then
    echo "✓ 全量备份成功"
    
    # 压缩备份文件
    tar -czf $BACKUP_FILE -C $BACKUP_DIR $DATE
    echo "✓ 备份文件已压缩: $BACKUP_FILE"
    
    # 清理临时目录
    rm -rf $BACKUP_DIR/$DATE
    
    # 保留最近 7 天的备份
    find $BACKUP_DIR -name "*.tar.gz" -mtime +7 -delete
    echo "✓ 已清理 7 天前的备份"
else
    echo "✗ 全量备份失败"
    exit 1
fi

echo "全量备份完成"

恢复策略 ​

  • 恢复测试：

    • 定期进行恢复测试，验证备份的可用性
    • 记录恢复时间，评估恢复效率

  • 恢复流程：

    1. 停止应用服务
    2. 恢复数据库
    3. 验证数据完整性
    4. 启动应用服务

  • 恢复示例：

bash
#!/bin/bash
# MariaDB 全量恢复脚本

BACKUP_FILE="/backup/mariadb/full/backup_20230101_000000.tar.gz"
RESTORE_DIR="/tmp/restore"

echo "开始执行全量恢复: $(date)"

# 停止 MariaDB 服务
systemctl stop mariadb

# 清理数据目录
rm -rf /var/lib/mysql/*

# 创建恢复目录
mkdir -p $RESTORE_DIR

# 解压备份文件
tar -xzf $BACKUP_FILE -C $RESTORE_DIR

# 使用 mariabackup 准备恢复
mariabackup --prepare --target-dir=$RESTORE_DIR/*

# 恢复数据
mariabackup --copy-back --target-dir=$RESTORE_DIR/*

# 修改数据目录权限
chown -R mysql:mysql /var/lib/mysql

# 启动 MariaDB 服务
systemctl start mariadb

# 验证恢复
if mysql -u root -p"password" -e "SELECT 1;" > /dev/null; then
    echo "✓ 数据库恢复成功"
else
    echo "✗ 数据库恢复失败"
    exit 1
fi

# 清理恢复目录
rm -rf $RESTORE_DIR

echo "全量恢复完成: $(date)"

4. 性能优化 ​

日常性能优化 ​

  • 查询优化：

    • 分析慢查询日志，优化查询语句
    • 优化索引设计，添加必要的索引
    • 删除无用索引，减少索引维护成本

  • 表优化：

    • 分析表碎片，使用 OPTIMIZE TABLE 优化表
    • 对于大表，考虑分区表或分库分表
    • 调整表结构，提高查询效率

  • 参数优化：

    • 根据业务需求调整数据库参数
    • 定期分析参数使用情况，进行必要的调整
    • 版本差异：MariaDB 10.3+ 引入了更多自动调优参数

性能分析工具 ​

  • 慢查询分析：

    • mysqldumpslow：简单的慢查询日志分析工具
    • pt-query-digest：Percona Toolkit 中的慢查询分析工具
    • MySQL Workbench：可视化慢查询分析工具

  • 性能监控：

    • SHOW STATUS：查看数据库状态
    • SHOW PROCESSLIST：查看当前进程
    • EXPLAIN/EXPLAIN ANALYZE：分析查询执行计划
    • Performance Schema：详细的性能监控数据（MariaDB 10.1+）
    • sys schema：提供易用的性能监控视图（MariaDB 10.0+）

安全管理 ​

1. 访问控制 ​

  • 用户管理：

    • 遵循最小权限原则，仅授予用户必要的权限
    • 定期清理无用用户
    • 使用强密码策略
    • 版本差异：MariaDB 10.4+ 支持密码验证插件 caching_sha2_password

  • 权限管理：

    • 使用角色管理权限，便于权限的统一管理
    • 定期审计用户权限
    • 限制用户的访问主机
    • 版本差异：MariaDB 10.0+ 支持角色管理

  • 示例：

sql
-- 创建角色
CREATE ROLE 'readonly';
CREATE ROLE 'readwrite';

-- 授予权限
GRANT SELECT ON ecommerce_db.* TO 'readonly';
GRANT SELECT, INSERT, UPDATE, DELETE ON ecommerce_db.* TO 'readwrite';

-- 分配角色给用户
GRANT 'readonly' TO 'app_user'@'192.168.1.%';
GRANT 'readwrite' TO 'admin_user'@'localhost';

2. 网络安全 ​

  • 端口管理：

    • 修改默认端口 3306，减少暴力攻击风险
    • 配置防火墙，只允许特定 IP 访问数据库端口

  • SSL/TLS 配置：

    • 启用 SSL/TLS 加密数据库连接
    • 使用有效证书，避免自签名证书
    • 版本差异：MariaDB 10.2+ 支持 TLS 1.3

  • 配置示例：

ini
# my.cnf 配置
[mysqld]
# 修改默认端口
port = 3307

# SSL/TLS 配置
ssl-ca = /etc/mysql/ssl/ca.pem
ssl-cert = /etc/mysql/ssl/server-cert.pem
ssl-key = /etc/mysql/ssl/server-key.pem
require_secure_transport = ON

3. 数据安全 ​

  • 数据加密：

    • 传输加密：使用 SSL/TLS 加密数据传输
    • 存储加密：
      • 表级加密：ENCRYPTED=YES（MariaDB 10.1+）
      • 列级加密：使用 AES_ENCRYPT() 和 AES_DECRYPT() 函数
      • 透明数据加密（TDE）：MariaDB 10.3+ 支持

  • 敏感数据保护：

    • 避免存储明文密码，使用哈希算法加密
    • 对敏感数据（如身份证号、手机号）进行脱敏处理
    • 限制敏感数据的访问权限

  • 审计日志：

    • 启用审计日志，记录数据库操作
    • 定期审计日志，查看是否有异常操作
    • 版本差异：MariaDB 10.3+ 支持审计插件 server_audit

4. 漏洞管理 ​

  • 补丁管理：

    • 定期更新 MariaDB 版本，修复已知漏洞
    • 测试补丁在测试环境中的兼容性
    • 制定补丁更新计划，避免业务高峰期更新

  • 安全扫描：

    • 使用安全扫描工具（如 Nessus、OpenVAS）定期扫描数据库服务器
    • 修复扫描发现的安全漏洞

  • CVE 响应：

    • 关注 MariaDB 官方发布的 CVE 信息
    • 及时评估 CVE 对系统的影响
    • 制定 CVE 修复计划

变更管理 ​

1. 变更流程 ​

  • 变更申请：

    • 填写变更申请表，包括变更内容、影响范围、风险评估、回滚方案
    • 变更申请表需经过审批

  • 变更执行：

    • 在测试环境中验证变更
    • 选择业务低峰期执行变更
    • 执行变更前进行备份
    • 执行变更时监控系统状态

  • 变更验证：

    • 验证变更是否达到预期效果
    • 检查系统是否正常运行
    • 验证业务功能是否正常

  • 变更记录：

    • 记录变更执行过程
    • 记录变更结果
    • 记录遇到的问题和解决方案

2. 变更类型 ​

  • 参数变更：

    • 调整数据库参数
    • 重启数据库服务（如果需要）
    • 验证参数变更效果

  • 表结构变更：

    • 添加、修改、删除表字段
    • 添加、修改、删除索引
    • 优化表结构
    • 版本差异：MariaDB 10.3+ 支持 ALTER TABLE ... ALGORITHM=INSTANT（部分操作）

  • 数据变更：

    • 批量导入、导出数据
    • 数据迁移
    • 数据修复

3. 回滚机制 ​

  • 回滚计划：

    • 针对每一次变更，制定详细的回滚计划
    • 回滚计划需经过审批

  • 回滚测试：

    • 在测试环境中测试回滚计划
    • 确保回滚计划的可行性

  • 回滚执行：

    • 当变更出现问题时，立即执行回滚
    • 回滚后验证系统状态

故障处理 ​

1. 故障分级 ​

  • P0：严重故障，影响核心业务，需立即处理

    • 数据库服务不可用
    • 主从复制中断，影响业务
    • Galera Cluster 分裂

  • P1：重要故障，影响部分业务，需尽快处理

    • 慢查询导致系统性能下降
    • 数据库连接数过高
    • 磁盘空间不足

  • P2：一般故障，不影响业务，需计划处理

    • 单表碎片过多
    • 无用索引过多
    • 日志文件过大

2. 故障处理流程 ​

  • 故障发现：

    • 通过监控系统发现故障
    • 通过用户反馈发现故障

  • 故障定位：

    • 查看系统日志和数据库日志
    • 检查系统资源使用情况
    • 分析慢查询日志
    • 使用性能分析工具定位问题

  • 故障处理：

    • 执行故障处理方案
    • 监控处理过程
    • 记录处理步骤

  • 故障恢复：

    • 验证故障是否恢复
    • 验证业务功能是否正常
    • 记录恢复时间

  • 故障总结：

    • 分析故障原因
    • 总结处理经验
    • 提出改进措施

3. 常见故障处理 ​

数据库服务不可用 ​

  • 处理步骤：

    1. 检查 MariaDB 进程是否运行
    2. 检查系统资源使用情况
    3. 检查数据库错误日志
    4. 尝试重启数据库服务
    5. 如果重启失败，分析失败原因

  • 示例：

bash
# 检查 MariaDB 进程
pgrep -x "mysqld"

# 检查系统资源
free -h
df -h
top

# 检查错误日志
tail -n 100 /var/log/mariadb/mariadb.log

# 尝试重启服务
systemctl restart mariadb

主从复制中断 ​

  • 处理步骤：

    1. 检查主从复制状态
    2. 查看错误日志，分析中断原因
    3. 修复中断原因
    4. 重新同步数据
    5. 验证主从复制状态

  • 示例：

sql
-- 检查主从复制状态
SHOW SLAVE STATUS\G;

-- 停止从库复制
STOP SLAVE;

-- 重置从库复制
RESET SLAVE;

-- 重新配置从库复制（基于 GTID）
CHANGE MASTER TO
    MASTER_HOST='master_host',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='repl_password',
    MASTER_PORT=3306,
    MASTER_AUTO_POSITION=1;

-- 启动从库复制
START SLAVE;

-- 再次检查主从复制状态
SHOW SLAVE STATUS\G;

慢查询导致性能下降 ​

  • 处理步骤：

    1. 查看当前运行的慢查询
    2. 分析慢查询日志
    3. 优化慢查询语句
    4. 添加必要的索引
    5. 验证优化效果

  • 示例：

sql
-- 查看当前运行的查询
SHOW PROCESSLIST;

-- 分析慢查询日志
SELECT * FROM mysql.slow_log ORDER BY start_time DESC LIMIT 10;

-- 优化查询语句（示例）
-- 原查询
SELECT * FROM orders WHERE order_date >= '2023-01-01';

-- 优化后（添加索引）
CREATE INDEX idx_order_date ON orders(order_date);

应急响应 ​

1. 应急组织 ​

  • 应急响应团队：

    • 负责人：协调应急响应工作
    • DBA：负责数据库故障处理
    • 开发人员：负责应用故障处理
    • 运维人员：负责系统故障处理
    • 业务代表：负责业务影响评估

  • 应急联系方式：

    • 建立应急联系群
    • 保存团队成员的紧急联系方式
    • 配置电话告警

2. 应急预案 ​

  • 数据库崩溃：

    • 启动备用数据库
    • 恢复数据
    • 切换应用连接

  • 主从复制中断：

    • 提升从库为主库
    • 重新配置复制
    • 切换应用连接

  • Galera Cluster 分裂：

    • 确定主分区
    • 关闭从分区节点
    • 重新加入从分区节点
    • 验证集群状态

3. 应急演练 ​

  • 定期演练：

    • 定期进行应急演练，测试应急预案的可行性
    • 演练内容包括：数据库崩溃、主从复制中断、Galera Cluster 分裂等

  • 演练评估：

    • 评估演练效果
    • 分析演练中遇到的问题
    • 优化应急预案

版本管理 ​

1. 版本选择 ​

  • 稳定版本：

    • 使用稳定版本，避免使用开发版本
    • 选择长期支持（LTS）版本，如 MariaDB 10.6 LTS、MariaDB 10.11 LTS

  • 版本生命周期：

    • 关注 MariaDB 版本的生命周期
    • 及时升级到新的 LTS 版本
    • 停止使用已结束生命周期的版本

2. 版本升级 ​

  • 升级前准备：

    • 制定升级计划
    • 备份数据库
    • 在测试环境中测试升级
    • 评估升级风险

  • 升级执行：

    • 选择业务低峰期执行升级
    • 执行升级前进行最后一次备份
    • 按照升级文档执行升级
    • 升级过程中监控系统状态

  • 升级后验证：

    • 验证数据库服务是否正常运行
    • 验证业务功能是否正常
    • 验证性能是否正常

  • 回滚计划：

    • 如果升级失败，执行回滚计划
    • 回滚后验证系统状态

文档管理 ​

1. 架构文档 ​

  • 架构图：

    • 绘制数据库架构图，包括主从架构、Galera Cluster 架构等
    • 架构图需定期更新

  • 架构说明：

    • 说明数据库架构的设计思路
    • 说明架构的优缺点
    • 说明架构的适用场景

2. 运维文档 ​

  • 日常运维手册：

    • 包含日常巡检、监控与告警、备份与恢复等内容
    • 包含常见故障处理步骤

  • 变更记录：

    • 记录所有变更操作
    • 记录变更内容、影响范围、执行结果

  • 应急预案：

    • 包含各种故障的应急预案
    • 包含应急联系方式

3. 知识库 ​

  • 常见问题：

    • 记录常见问题和解决方案
    • 定期更新知识库

  • 最佳实践：

    • 记录数据库运维的最佳实践
    • 分享运维经验

常见问题 (FAQ) ​

Q: 如何处理 MariaDB 服务无法启动的问题？ ​

A: 处理步骤：

  1. 检查 MariaDB 错误日志，查看具体错误信息
  2. 检查数据目录权限是否正确（mysql:mysql）
  3. 检查磁盘空间是否充足
  4. 检查内存是否充足
  5. 检查配置文件是否有语法错误
  6. 尝试使用 mysqld_safe 启动，查看详细错误信息
  7. 如果是数据损坏，尝试使用 mysqlcheck 修复表

Q: 如何优化 MariaDB 性能？ ​

A: 性能优化建议：

  1. 硬件优化：使用高性能 CPU、足够的内存、SSD 存储
  2. 参数优化：调整 innodb_buffer_pool_size、innodb_log_file_size、max_connections 等参数
  3. 索引优化：添加必要的索引，删除无用索引
  4. 查询优化：分析慢查询日志，优化查询语句
  5. 表结构优化：优化表结构，减少表碎片
  6. 架构优化：使用主从复制、读写分离、Galera Cluster 等架构

Q: 如何确保 MariaDB 数据安全？ ​

A: 数据安全建议：

  1. 访问控制：遵循最小权限原则，定期审计用户权限
  2. 网络安全：启用 SSL/TLS 加密，配置防火墙
  3. 数据加密：使用存储加密、传输加密
  4. 备份策略：遵循 3-2-1 备份原则，定期验证备份
  5. 安全审计：启用审计日志，定期审计数据库操作
  6. 漏洞管理：及时更新 MariaDB 版本，修复已知漏洞

Q: 如何处理主从复制延迟问题？ ​

A: 主从复制延迟处理：

  1. 检查网络连接，确保主从节点之间网络稳定
  2. 检查主库的写压力，考虑分流写操作
  3. 调整从库的 slave_parallel_threads 参数，增加并行复制线程数
  4. 确保从库的硬件配置不低于主库
  5. 检查从库的慢查询，优化查询语句
  6. 考虑使用 GTID 复制，提高复制效率

Q: 如何选择合适的备份策略？ ​

A: 备份策略选择：

  1. 根据数据量：小数据量使用 mysqldump，大数据量使用 mariabackup
  2. 根据业务需求：
    • RTO（恢复时间目标）要求高：使用热备份
    • RPO（恢复点目标）要求高：增加备份频率
  3. 根据存储条件：考虑存储成本和可用性
  4. 定期验证备份：确保备份的可用性
  5. 异地备份：防止本地灾难导致数据丢失

Q: 如何处理 Galera Cluster 分裂问题？ ​

A: Galera Cluster 分裂处理：

  1. 确定主分区：查看各节点的 wsrep_cluster_size 和 wsrep_incoming_addresses
  2. 关闭从分区节点：使用 systemctl stop mariadb
  3. 启动主分区节点（如果需要）：使用 systemctl start mariadb
  4. 重新加入从分区节点：启动从分区节点，等待自动同步
  5. 验证集群状态：使用 SHOW GLOBAL STATUS LIKE 'wsrep%'; 检查集群状态

Q: 如何制定数据库扩容计划？ ​

A: 扩容计划制定：

  1. 容量评估：分析数据增长趋势，预测未来容量需求
  2. 扩容方案：
    • 垂直扩容：升级硬件配置
    • 水平扩容：增加节点数量，使用主从复制、Galera Cluster 等架构
    • 分库分表：将大表拆分为多个小表
  3. 扩容测试：在测试环境中验证扩容方案
  4. 扩容执行：选择业务低峰期执行扩容
  5. 扩容验证：验证扩容效果，确保系统正常运行

Q: 如何监控 MariaDB 性能？ ​

A: 性能监控建议：

  1. 监控工具：使用 Prometheus + Grafana、PMM 等监控工具
  2. 关键指标：
    • 系统指标：CPU、内存、磁盘 I/O、磁盘空间
    • 数据库指标：连接数、查询性能、缓冲池使用情况、锁等待情况、事务情况
  3. 告警设置：设置合理的告警阈值，及时发现问题
  4. 性能分析：定期分析性能数据，优化系统性能

总结 ​

MariaDB 运维规范是确保数据库系统稳定运行、高性能和高可用的重要保障。本规范涵盖了日常运维流程、监控与告警、备份与恢复、性能优化、安全管理、变更管理、故障处理、应急响应、版本管理和文档管理等方面的内容。

遵循运维规范能够帮助运维团队：

  • 提高系统可靠性和可用性
  • 减少人为错误
  • 提高运维效率
  • 降低系统风险
  • 确保数据安全
  • 便于团队协作和知识传承

运维规范不是一成不变的，需要根据业务发展和技术进步不断更新和完善。建议定期 review 和更新运维规范，确保其始终适应业务需求和技术趋势。