华为云云数据库GaussDB实战：实例创建、连接接入、分布式与主备、参数调优与备份恢复

一、背景：为什么把业务库放到GaussDB

自建库迁到云上，或新业务直接在云上建库时，常见纠结是：要不要自己搭高可用、怎么做备份和恢复演练、连接地址怎么对应用暴露、参数要不要一上来就改。自己在云主机上装库，安装并不难，难的是主备切换、备份保留、监控和扩容都要自己兜底。

华为云云数据库GaussDB把实例开通、高可用、备份和参数管理收进控制台，内核兼容常见的关系型用法，同时提供主备和分布式两种形态。它和自己在云主机里装的数据库不是一回事——后者操作系统、存储和高可用都要自己维护，GaussDB是托管实例，你负责业务模型和连接，平台负责实例运行和备份任务。本文按“认清形态 → 创建实例 → 完成连接 → 按需调参 → 备份恢复”的顺序实操一遍。菜单名称以控制台当前版本为准。

二、核心概念

实例：一次开通对应一套可连接的数据库服务，包含计算规格、存储容量、可用区、网络和账号。实例访问地址记为 <实例地址>，端口记为 <端口>，不要把真实地址写进对外文档。

主备版：一主一备或一主多备，备机承担故障切换，适合大多数中小规模业务，先按单库模型设计表结构即可。

分布式版：数据按规则分布到多个数据节点，前面由协调节点承接会话和语句，适合数据量和并发明显超出单机上限、并且愿意按分布键设计表的业务。

参数模板：一套可复用的参数集合，可挂到同类实例上。改参数前先看是否需要重启，生产上不要直接在页面上试运气。

自动备份与手动备份：自动备份按策略定期生成，并支持在保留期内做按时间点恢复；手动备份适合变更前打快照。恢复通常是拉起新实例，而不是覆盖正在提供服务的库。

三、创建实例

进入云数据库GaussDB控制台，选择与业务相同的区域后创建实例：

1. 选择形态：主备或分布式。不确定时先选主备，避免还没想清楚分布键就上分布式；
2. 填写实例名称，建议带环境和用途，例如 gaussdb-prod-core；
3. 选择引擎版本、规格和存储。规格看CPU、内存与连接数，存储要留出数据增长、临时文件和备份峰值的余量；
4. 选择可用区和高可用部署。生产尽量让主备落在不同可用区，避免单可用区故障同时打到两端；
5. 配置网络：虚拟私有云、子网和安全组。安全组入方向只放行应用或堡垒机访问 <端口>，不要对全部地址完全放开；
6. 设置管理员账号，用户名记为 <管理员用户>，密码只通过安全渠道保管，不要写进代码仓库或公开文档；
7. 打开自动备份，设好备份窗口和保留天数，窗口避开业务高峰；
8. 确认计费方式和磁盘加密等选项后提交，等待实例状态变为可用，再记录 <实例地址> 和 <端口>。

创建阶段最容易忽略的是安全组和备份窗口。实例已经“可用”只说明数据库进程起来了，不代表应用所在网段能连上，也不代表备份策略已经符合恢复目标。

规格建议按峰值连接和内存来选，而不是只看平均CPU。磁盘选太小，后期扩容要改时间窗；选太大则一直为用不到的空间付费。测试环境可以先用较小规格走通连接和备份，再在生产用正式规格。

四、连接实例

实例可用后，先在控制台查看连接信息，再从同一虚拟私有云内的云主机或已打通的应用网段测试。公网访问不是默认选项，生产库优先走内网，少暴露面。

用客户端连接时，一律填占位符，不要把真实地址写进文档：

gsql -h <实例地址> -p <端口> -d <数据库名> -U <管理员用户>

应用侧把主机、端口、库名和用户写成配置项，例如：

主机=<实例地址>
端口=<端口>
数据库=<数据库名>
用户=<业务用户>

建议单独建业务账号，不要让应用直接使用 <管理员用户>。业务账号只授需要的库和表权限，密码轮换和账号禁用才好落地。连接数要在参数和应用连接池之间对齐，池开太大，实例会先被连接占满，而不是被SQL打满。

连不上时按这个顺序查，不要反复重建实例：安全组是否放行应用网段到 <端口>、应用是否和实例在可互通的网段、地址和端口是否填成了只读地址或历史实例、账号密码是否被重置、SSL要求是否与客户端一致。测试通过后再把连接配置进应用，先做一次建表、写入和查询，确认字符集、时区与业务预期一致。

如果开通了只读地址，读多写少的业务可以把查询分到只读连接，写入仍走主地址。注意复制延迟：对延迟敏感的读，不要只看“有只读地址”就全部切过去。

五、分布式与主备，怎么选、怎么用

主备版的模型更接近单机库：表不用强制选分布键，事务和关联查询的心智负担更小，运维重点是主备状态、切换演练和备份。适合订单、配置、中小规模核心库，以及还在快速改表结构的早期业务。

分布式版把数据打散到多个数据节点，容量和部分并行能力更好，但表设计要提前想清楚：

1. 为事实表选择稳定、查询常带、取值分散的分布键，避免所有流量打到同一个数据节点；
2. 经常一起关联的表，尽量使用相同的分布键，减少跨节点加数据重分布；
3. 全局表只留给变更少、体积小的字典或配置数据，不要把大表做成全局表；
4. 避免没有过滤条件的大表关联和跨节点事务堆积，语句要能在执行计划里看懂数据移动。

已经在主备版跑得很好的业务，不要只因为“以后可能很大”就提前拆成分布式。相反，数据量或连接数已经接近单机上限、且业务能接受按分布键改造时，再评估分布式。无论哪种形态，生产都要关注主备或节点是否健康，切换后应用是否能自动重连，而不是假设连接会一直活着。

形态选定后不要频繁互迁。表结构、主键和分布键一旦带进生产，后期调整成本会明显高于创建实例时多看一眼需求。

六、参数调优

先把慢查询、连接数、CPU、内存和磁盘刷写看清楚，再改参数。没有负载证据时不要凭经验把内存相关参数一次性拉满，容易挤占操作系统和缓存，也给后续排查增加变量。

优先核对这几类参数，具体名称以控制台当前版本的参数列表为准：

连接与并发：最大连接数要大于应用连接池总和，并留运维余量。连不上时先看是连接打满还是语句阻塞，不要一上来就加规格。

内存：缓存和排序、哈希、维护操作相关的内存，要按规格和语句类型调整。复杂查询和索引构建会吃临时内存，设太小会落到磁盘，设太大在高并发下会争抢。

日志与刷写：提交刷盘、检查点相关参数影响突发写入的稳定性和故障恢复时间。追求极致提交延迟时，先确认能接受的数据安全级别，不要只在测试库上看延迟数字。

自动清理与统计信息：更新多、膨胀快的表要保证自动清理能跟上，统计信息过旧会让执行计划走偏。调参解决不了缺失索引或糟糕的表设计，这两件事要分开处理。

改参数时优先写入参数模板，再应用到目标实例，并记录变更单：改了哪些项、是否需要重启、回退值是什么。必须重启的参数放到维护窗口，先在同等规格的测试实例上用真实SQL验证。调完后继续观察一段时间的慢查询和资源曲线，没有改善就回退，不要叠加上一轮没有结论的修改。

七、备份恢复

备份不是“已经打开自动备份”就算完成，而是要能在目标时间内恢复出可用实例。先在内部写清两个数字：最多能丢多长时间的数据，以及出故障后多久必须恢复服务。保留天数必须覆盖这两个目标，还要留出发现问题的时间。

建议把下面几件事做成固定动作：

1. 自动备份窗口放在业务低谷，保留期覆盖最近一次可接受的回退点；
2. 重大变更、批量操作或结构升级前打一份手动备份，并确认备份任务成功结束；
3. 定期做恢复演练：选择某个时间点，恢复到新实例，地址记为 <恢复实例地址>，不要直接在生产实例上做覆盖式恢复；
4. 演练时核对关键表行数、抽样数据和账号权限，再让应用连到 <恢复实例地址> 做只读校验；
5. 确认无误后，才在变更窗口决定是否切流；演练用的实例及时释放，避免一直计费。

恢复失败常见原因是保留期不够、备份窗口内实例负载过高导致备份超时、恢复出来的版本或规格与预期不符，以及应用仍连着旧的 <实例地址>。出了问题先保住当前库和最近一份成功备份，再查任务日志，不要同时发起多次互相覆盖的恢复。

备份内容包含数据，因此备份的访问权限和恢复出来的实例网络，都要按生产库同等收紧。恢复演练记录只写占位符，不写真实地址和账号。

需要记录核对命令时，同样用占位符。例如：

-- 在当前实例和恢复实例分别执行，核对本表行数
SELECT COUNT(*) FROM <业务表名>;

八、小结

GaussDB的关键不是把实例“创建出来”，而是四件事同时正确：形态选对（主备还是分布式）、网络和账号只暴露必要范围、参数跟着负载改并留回退、备份能在演练中恢复出可用库。先用一张表把 <实例地址>、<端口>、形态、规格、备份保留期和恢复目标对齐，再在控制台开通实例并完成连接测试，最后把调参和恢复演练纳入日常变更，这样比在云主机里自建库更省高可用和备份方面的精力，也比只开通不做演练更安全。

生产环境还要考虑：连接池与最大连接数匹配、主备或节点故障后的重连、分布式表的分布键设计，以及恢复演练后的实例回收。地址和账号只放在内部变更单里，不要出现在公开博客或代码仓库中。