一、架构设计与高可用目标
高可用数据库架构的核心目标是实现业务连续性，降低单点故障带来的停机时间。在设计阶段，我们需要明确容错级别、可扩展性与数据一致性的权衡，确保在硬件或网络故障时系统能够自动恢复。
多节点协同与故障域划分是实现高可用的基础。通过将节点分布在不同机房或不同物理机上，可以有效降低区域性故障对数据库的影响，同时通过集群管理软件（如 Pacemaker/Corosync、Keepalived）实现对节点的监控与切换。
子标题A
集群化设计的核心组件包括仲裁、状态同步与资源管理，它们共同保障在出现故障时可以进行快速且可控的故障转移。
拓扑方案的选型决定了可用性边界，常见的方案有主动-主动（多主）与主动-待机（主从/备用）两类，需结合数据库类型与应用特征进行取舍。
子标题B
高可用堆栈的关键技术栈通常包含Pacemaker、Corosync、STORK/STONITH与Keepalived等组件，用以实现集群状态的一致性与机器级保护。
此外，故障转移延迟与网络分区处理策略对业务体验影响显著，设计时应评估切换时间、一致性等级与数据丢失容忍度等。
二、常见高可用数据库解决方案与选型
子标题C
MySQL/MariaDB Galera 集群提供同步复制能力，适用于需要强一致性的场景，但对网络延迟较敏感。通过在每个节点部署数据库实例并配置wsrep，可以实现多主写入与自动故障转移。
Galera 集群的复制特性让任一节点写入都能被复制至其余节点，从而实现数据的高可用与水平扩展，但需要确保 网络延迟低且带宽充裕，以维持一致性和性能。
# MySQL Galera 集群简化示例（三节点）
[mysqld]
wsrep_on=ON
wsrep_provider=/usr/lib64/galera3/libgalera_smm.so
wsrep_cluster_address="gcomm://node1,node2,node3"
wsrep_cluster_name="galera_cluster"
wsrep_node_address="node1"
wsrep_node_name="node1"
子标题D
PostgreSQL 的高可用方案（如 Patroni + etcd/Consul）提供自动化的主备切换与一致性保证，适用于对 PostgreSQL 的原生特性依赖较高的场景。
Patroni 通过 分布式配置存储和 心跳检测 实现自动故障转移，同时结合 WAL 机制确保数据的一致性和可恢复性。
# Patroni 配置片段示意
scope: postgres
namespace: /service/
name: my-postgres
restapi:port: 8008
etcd:hosts: [ "etcd1:2379", "etcd2:2379" ]
postgresql:listen: 0.0.0.0:5432
bootstrap:dcs:ttl: 30loop_wait: 10retry_timeout: 30
三、故障转移流程与一致性保障
子标题E
故障检测与切换触发机制是高可用的第一道防线。通过
ST O N I T H（节点保护）与仲裁门槛确保在分布式环境中不会因少数节点失效导致整组系统不可用，避免脑裂和数据不一致。
# 使用 pcs 设置基础监控与资源
pcs status
pcs property set stonith-enabled=true
子标题F
数据一致性保障与恢复流程要求在故障转移时仍然确保已提交的事务一致性，并且在主节点恢复后进行无损回放或回滚。
复制延迟与写入安全性是关键考量，通常需要配置同步复制路径、提交确认等级与断点续传/日志传输，以避免丢失未提交的变更。
# PostgreSQL 同步复制简要配置示例
synchronous_standby_names = 'standby1, standby2'
wal_level = replica
max_wal_senders = 10
四、部署步骤与示例配置
子标题G
环境准备与依赖安装是落地实施的第一步。应确保两台及以上节点具备一致的 Linux 发行版、时钟同步（NTP）和基本网络连通性。
版本控制与变更管理能帮助团队回溯配置演变，使用Git 版本库记录集群配置、灾难演练脚本与备份策略。
# 常见环境准备示例（Ubuntu/Del）：
apt-get update
apt-get install -y pacemaker corosync pcs keepalived
ntpdate pool.ntp.org
子标题H
Pacemaker/Corosync 的安装与初始配置提供了对资源、约束和STONITH的集中管理能力，通过 crmsh 或 pcs 命令可实现集群初始化与状态检查。
初始集群状态的验证有助于在上线前发现拓扑配置错误，确保在正式切换前集群处于可用状态。
# 安装和基础检查
apt-get install -y pacemaker corosync crmsh
crm status
pcs status
# 配置一个简单的 MySQL 资源与监控
pcs resource create mysql ocf:heartbeat:mysql \config="/etc/mysql/my.cnf" op monitor interval=30s timeout=60s
pcs constraint colocation add mysql with remote mysql
子标题I
数据库实例的角色分配与资源驱动决定了故障转移时的优先级与行为。合理的资源分配可以降低切换时的业务中断。
针对不同数据库的资源代理如 ocf:heartbeat:mysql、ocf:heartbeat:pgsql，需结合实际数据库版本和系统环境进行调整。
# MySQL 资源定义示例（Pacemaker）
pcs resource create mysql ocf:heartbeat:mysql \config="/etc/mysql/my.cnf" op monitor interval=30s timeout=60s
pcs constraint order start mysql then start web-service
五、监控、备份与运维实践
子标题J
监控指标与告警体系是持续可用性的保障。应覆盖集群状态、网络延迟、复制延迟、磁盘 I/O 与数据库性能指标，并接入Prometheus+Grafana、Alertmanager等工具实现可视化与告警。
告警策略应覆盖节点不可用、切换等待时间过长、数据复制延迟等关键场景，确保运维人员能够在第一时间响应。
# Prometheus 监控示例片段
- job_name: 'pgsql'static_configs:- targets: ['node1:9187','node2:9187']
子标题K
备份策略与演练流程直接关系到灾难发生时的数据可恢复性。常用的备份方式包括全量备份、增量备份与二进制日志的组合。
定期演练能够帮助团队验证切换时间、数据一致性与恢复路径，确保在真实场景中能够快速高效地恢复服务。
# PostgreSQL 基本备份示例
pg_basebackup -h primary -D /backup/postgres -Fp -Xs -U replicator
# MySQL 逻辑备份示例
mysqldump -u root -p --all-databases > /backup/all_databases.sql
