1. 存储与 IO 性能基线评估（Storage IO Baseline）
1) 测试目的：评估不同存储类型（本地 NVMe、云盘 SSD、云盘 HDD）在随机 4KB/顺序读写下的 IOPS 与延迟。
2) 推荐工具：使用 fio（示例：fio --name=randread --ioengine=libaio --rw=randread --bs=4k --numjobs=8 --size=4G --runtime=60 --group_reporting）。
3) 常见云盘结果示例（如下表格有居中展示）：本地 NVMe 明显优于云盘 SSD，HDD 大幅落后。
4) 测试注意项：先清缓存（echo 3 > /proc/sys/vm/drop_caches），保障测试间隔、网络抖动最小。
5) 结论：数据库 I/O 敏感，应优先选择本地 NVMe 或高 IOPS 的云块存储，并做性能基线记录以便回溯。
2. 存储性能对比（示例数据表）
1) 下面给出一次在香港节点上对三类存储的 fio 4KB randread/randwrite 简化结果示例：
2) 表格用于直观比较 IOPS 与平均延迟（注意：为演示数据，实际数值请以具体测得为准）。
3) 表格居中显示，边框宽度为1，单元格文字居中。
4) 通过表格可见 NVMe 在随机读写场景 IOPS 和延迟优势明显，适合高并发事务型数据库。
5) 根据结果选择成本/性能折衷：读密集可考虑云SSD并配本地缓存，写密集尽量使用本地 NVMe 或专属高IOPS云盘。
| 存储类型 | 4KB RandRead IOPS | 4KB RandWrite IOPS | 平均延迟(ms) |
|---|
| 本地 NVMe | 180,000 | 150,000 | 0.4 |
| 云盘 SSD (高IO) | 12,000 | 10,000 | 1.8 |
| 云盘 HDD | 200 | 180 | 12.5 |
3. 持久化策略：数据库级参数（MySQL / InnoDB 与 PostgreSQL）
1) MySQL（InnoDB）关键参数：innodb_flush_log_at_trx_commit、sync_binlog、innodb_flush_method。示例：innodb_flush_log_at_trx_commit=1, sync_binlog=1 在强一致性下写放大高；设置 =2 或 =0 可提升写吞吐，但降低单次崩溃保证。
2) MySQL 优化示例：innodb_buffer_pool_size=24G（在32G内存下），innodb_io_capacity=2000（对应 NVMe/云盘能力），innodb_flush_method=O_DIRECT。
3) PostgreSQL 关键参数：synchronous_commit、wal_level、checkpoint_completion_target。示例：synchronous_commit=on（强一致性）或 =off（性能优先），wal_sync_method=pdatasync/fsync 需根据底层 FS。
4) 示例配置（适用于写密集 OLTP，8vCPU/32GB/1TB NVMe）：Postgres: shared_buffers=8GB, effective_cache_size=24GB, wal_buffers=16MB, max_wal_size=2GB。
5) 建议：在 HK 云上先通过小型压力测试确定事务延迟与磁盘 fsync 行为，再决定是否采用异步复制或更激进的 flush 策略。
4. 持久化与高可用架构（Replication / Backup / DR）
1) 主从复制：异步复制降低主库延迟但可能丢数据，半同步复制可折中（MySQL semi-sync，Postgres synchronous_commit=remote_apply）。
2) 多 AZ 与多机房：香港云可能提供不同可用区，建议在跨可用区建立异步副本并定期故障演练。
3) 备份策略：全备 + 增量（例：每日全备 + 每小时增量），并将备份异地（如新加坡或阿里云香港备份桶）。
4) PITR（Point-in-time recovery）：开启 binlog/WAL 日志归档，保存时长按 RTO/RPO 定制（例如 7 天或 30 天），并测试恢复流程。
5) 灾难恢复演练：定期恢复演练，验证恢复时间（RTO）与恢复点（RPO），并记录真实恢复耗时。
5. 网络、域名、CDN 与 DDoS 防御考量
1) 网络延迟：香港对东南亚/中国大陆延迟较低（示例：香港->新加坡 10~15ms，香港->深圳 10~30ms，视ISP而定），数据库跨域部署需考虑同步延迟。
2) 域名与连接：将数据库访问限制在内网子网，域名仅用于应用层连接，避免公网直连数据库。
3) CDN 使用场景：静态资源与缓存层使用 CDN（如 Cloudflare / 阿里云 CDN）可减轻 origin 负载，但数据库流量不能走 CDN。
4) DDoS 防御：在香港云使用云厂商提供的 Anti-DDoS / WAF，数据库端口尽量不对外暴露，应用层通过反向代理或负载均衡器保护。
5) 网络带宽与突发：为数据库节点申请足够的带宽与 QoS 策略，避免网络拥塞导致复制或备份窗口延长。
6. 真实案例：电商平台在香港云部署 MySQL 的配置与表现
1) 背景：某电商在香港节点，日峰值订单峰值 2 万笔/小时，要求 RPO<=1min，RTO<=30min。
2) 主机配置：8 vCPU (Intel Cascade Lake)、32GB RAM、2 x 1TB 本地 NVMe（RAID1 用作 OS 与日志分离）、云块存储 1TB（数据盘做 RAID10）。
3) MySQL 配置要点：innodb_buffer_pool_size=24G, innodb_flush_log_at_trx_commit=1, sync_binlog=1, innodb_io_capacity=200000（匹配 NVMe 峰值）。
4) 性能结果（生产模拟压测）：事务吞吐约 6,500 tps，99% 响应时间 < 12ms，磁盘 4KB randwrite IOPS 峰值测得 120k。
5) 持久化与备份：采用半同步复制到同区域只读副本 + 异地异步备份到新加坡对象存储，binlog 保留 48 小时，日备保留 14 天。
7. 系统级与运维建议（内核、文件系统与监控）
1) 文件系统与挂载：推荐 XFS 或 ext4 + noatime，日志目录单独挂载，MySQL/Postgres 使用 O_DIRECT 避免双层缓存。
2) 内核与 I/O 参数：调整 vm.dirty_ratio (~10)、vm.dirty_background_ratio (~5)、ulimit -n 至 100k，调整 tcp_tw_reuse/tcp_fin_timeout 等网络参数。
3) RAID 与快照：数据库采用 RAID10 保证读写性能与冗余；云快照用于快速恢复，但快照一致性需在数据库层 quiesce（flush）后触发。
4) 监控与告警：监控磁盘 IOPS、延迟、fsync 时间、WAL/redo 延迟、复制滞后、网络抖动，设置阈值告警并自动化扩容/切换脚本。
5) 运维演练：每季度进行切换、备份恢复、IO 压力测试，记录性能回归数据以便容量规划。
来源：数据库部署香港云服务器的配置 IO 性能与持久化策略配置建议
