1. 连接设置从“门卫”到“会客厅”的精细化管理刚接触GaussDB那会儿我最头疼的就是客户端连不上数据库。明明服务起来了IP也对端口也没错可就是报“连接被拒绝”。后来才发现问题出在最基础的“门卫”配置上也就是连接设置参数。这部分参数就像是大楼的门禁系统和会客厅的容量规划决定了谁能进、从哪进、能进多少人。1.1 监听地址与端口数据库的“门牌号”和“大门”listen_addresses这个参数你可以把它理解成数据库服务在哪几个“网络接口”上竖起耳朵听动静。默认值是localhost这意味着它只监听本机回环地址127.0.0.1。如果你在本机用gsql或者应用连接没问题。但一旦你的应用服务器和数据库服务器是分开的两台机器连接请求从远程过来数据库根本“听不见”自然就拒绝了。我踩过的坑是在云服务器上部署GaussDB应用部署在另一台ECS上。配置时想当然地用了默认值结果应用死活连不上。排查了半天网络最后才发现是listen_addresses没改。正确的做法是根据你的网络规划来设置。如果数据库只给内网特定几台机器访问就写上这些机器的IP比如‘192.168.1.100, 192.168.1.101’。如果需要被所有网络接口访问注意生产环境慎用有安全风险可以设置为‘*’。我个人的经验是在测试环境为了方便可以设成‘0.0.0.0’或‘*’但在生产环境一定要精确到具体的IP或网段这是安全的第一道防线。port参数就是具体的“门牌号”了默认是5432。这个端口号是可以改的范围在1024到65535之间。改端口通常有两个场景一是安全考虑避免使用默认端口减少被扫描攻击的风险二是一台服务器上要部署多个GaussDB实例需要用不同端口区分。修改后客户端连接时就必须显式指定这个新端口。这里有个小提醒修改端口后别忘了同步更新防火墙如iptables, firewalld规则放行新的端口不然又会掉进“连接被拒绝”的坑里。1.2 最大连接数与管理员预留会客厅的“容量”与“VIP通道”max_connections决定了数据库同时能接待多少“客人”并发连接。默认值是100对于小型应用或测试环境可能够用但稍微有点规模的线上业务这个数就捉襟见肘了。不过调大这个参数不是简单地改个数字就行。每个连接都会占用一定的内存和系统资源如信号量、共享内存。盲目调大比如一下子调到1000很可能导致数据库启动时就因为申请不到足够的系统共享内存而失败。我建议的做法是循序渐进。先根据业务预估的峰值并发量设定一个初始值比如500。然后通过监控系统观察pg_stat_activity视图看活跃连接数是否经常接近这个上限。如果经常打满再考虑适当调大。同时一定要同步调整操作系统的内核参数特别是kernel.sem信号量、kernel.shmall、kernel.shmmax共享内存这些具体调整方法可以参考GaussDB的官方安装文档。调小这个参数更要小心如果当前有连接数超过新设置的值数据库可能无法以主模式primary启动需要先以单用户模式或调整模式处理。superuser_reserved_connections这个参数特别重要它相当于给数据库管理员DBA预留了几个“VIP通道”。假设max_connections500这个参数设为3那么普通用户最多能建立497个连接。当连接数达到497后普通用户就无法再连接了但DBA用户如初始用户依然可以通过这3个预留通道连上去进行紧急维护比如排查是什么连接占满了资源或者Kill掉一些异常会话。这个值一般不用改太大3到5个就足够了关键是确保在关键时刻有“救命”的入口。1.3 Unix域套接字与TCP保活高效本地通信与连接健康检查如果你的应用和GaussDB部署在同一台物理机或虚拟机内那么使用Unix域套接字Unix Domain Socket连接是性能更高、更安全的选择。它绕过了繁琐的TCP/IP协议栈直接通过文件系统进行通信。相关参数有三个unix_socket_directory指定套接字文件存放的目录。默认是空会放在数据目录下。你可以指定到一个像/tmp或/var/run/postgresql这样的目录。unix_socket_group和unix_socket_permissions这两个参数一起控制访问权限。比如你把unix_socket_permissions设置为0700就意味着只有启动数据库的操作系统用户自己能连接设置为0770则同组的用户也能连接。生产环境下强烈建议不要用默认的0777谁都能连这等于把后门敞开了。再来说说TCP保活参数tcp_keepalives_idle,tcp_keepalives_interval,tcp_keepalives_count。这组参数是解决“幽灵连接”或“半开连接”问题的利器。想象一下一个客户端应用崩溃了或者网络中间设备如防火墙静默地断开了连接但数据库端并不知道还以为这个连接活着一直占着资源。TCP保活机制就是数据库端定期向客户端发送“心跳包”来探测连接是否真的健康。tcp_keepalives_idle连接空闲多久后开始发第一个心跳包默认0依赖系统设置。tcp_keepalives_interval第一个心跳包没回应隔多久发下一个。tcp_keepalives_count连续发多少个心跳包都没回应就认定连接已死断开它。在长连接应用如连接池、某些中间件场景下合理配置这些值非常有必要。例如在一个网络不太稳定的跨机房环境中我通常会设置idle3005分钟interval30count3。意思是连接空闲5分钟后开始探测每30秒发一次心跳连续3次即1.5分钟没回应就断开。这样可以及时释放被无效连接占用的资源。注意这些参数需要操作系统内核支持对应的TCP选项才生效。2. 连接池配置资源复用的“调度中心”直接让应用连接数据库每个请求都新建一个连接在高并发场景下简直是灾难。建立TCP连接和数据库认证本身就有开销而且每个连接都会占用后端进程和内存。连接池就是为了解决这个问题而生的“调度中心”它预先建立好一批到数据库的连接放在池子里管理应用需要时从池里取一个用用完了还回去而不是关闭。2.1 连接池模式选择会话、事务与语句级GaussDB的连接池功能通过pooler_mode控制非常灵活提供了几种不同粒度的复用模式选对模式是关键。会话级连接池session这是最符合传统认知的模式。客户端从连接池获得一个连接后在整个会话生命周期内都独占这个连接直到客户端主动断开连接才被池子回收。这种模式兼容性最好几乎支持所有数据库特性如临时表、会话变量SET等。适合那些需要保持会话状态的传统应用。事务级连接池transaction这是GaussDB推荐用于高并发OLTP场景的模式。客户端只有在执行一个事务BEGIN...COMMIT时才会从池子里分配一个真实的数据库连接。事务一结束提交或回滚连接立刻被回收可以马上分配给其他客户端的事务使用。这里有个重要限制因为连接会被不同客户端交替使用所以与会话相关的功能比如用PREPARE创建的预备语句、用SET命令设置的会话级参数在事务结束后就失效了。如果你的应用大量依赖这些特性需要评估或改造。语句级连接池statement粒度更细每条SQL语句执行时都会申请和释放连接。这种模式对连接的复用率最高但开销也最大因为每条语句都要经历一次“借还”过程。通常用在一些特殊的代理或中间件场景普通业务直接用的不多。我个人的经验是对于全新的微服务或无状态应用优先考虑事务级连接池。它能用很少的数据库后端连接max_connections来支撑大量的应用并发极大地节省了数据库资源。对于遗留系统或使用了大量会话特性的应用可以先从会话级连接池开始再逐步向事务级迁移。2.2 核心参数调优容量、水位与生命周期开启连接池后一系列参数决定了这个“调度中心”的运行效率。我把它们分成三类容量规划、弹性水位和连接健康度。容量规划参数pooler_max_conn连接池进程自身能接受的最大客户端并发连接数。这个值通常会设得比max_connections大很多因为连接池的存在就是为了让更多客户端“虚拟连接”复用少量“物理连接”。default_pool_size这是最重要的参数之一定义了每个用户数据库组合在池中保持的“常驻”连接数。例如应用用户appuser连appdb池子里会为这个组合保持最多20个默认活跃的物理连接。设置太小可能导致频繁创建新连接设置太大又浪费资源。你需要根据这个用户的实际并发压力来调整。弹性水位参数min_pool_size池子里为每个用户数据库组合保留的最小空闲连接数。即使没有请求也保持这些连接活着以便快速响应突发请求。对于核心业务可以适当设置一个值如5避免冷启动延迟。reserve_pool_size和reserve_pool_timeout这俩是一对。当所有常驻连接default_pool_size都被占用时如果还有新的请求连接池不会立刻拒绝而是尝试等待reserve_pool_timeout默认5秒看有没有连接被释放。如果等不到它就会动用“备用连接池”大小由reserve_pool_size定义来创建新的物理连接处理请求。用完后这个备用连接会在空闲一段时间后被回收。这个机制非常适合应对突发流量相当于一个缓冲带。连接健康度参数pooler_server_lifetime一个物理连接在池子里的最长寿命分钟。即使这个连接是健康的到了时间也会被强制关闭然后池子会新建一个连接补充进来。这有助于定期刷新连接避免某些长期存在的连接因底层TCP或数据库后端进程的隐形问题导致性能下降。我一般会设置为几小时如240分钟。pooler_server_idletime物理连接在池子里空闲多久后可以被关闭以释放资源。如果你的业务有明显的波峰波谷比如白天忙晚上闲设置这个参数如30分钟可以在闲时自动收缩资源。配置示例一个典型的电商应用用户trade_user访问trade_db日常并发50峰值可能到200。我的配置可能是default_pool_size30,min_pool_size5,reserve_pool_size20,reserve_pool_timeout3。这样平时有5个保底连接30个常驻连接应对日常突发时还有20个备用连接作为缓冲整体比较平滑。3. 安全与认证构筑数据库的“护城河”数据库安全无小事认证环节是防御的第一关。GaussDB在这方面提供了从连接控制到密码策略的全套参数。3.1 连接超时与SSL加密守好入口和通道authentication_timeout这个参数经常被忽略但它很重要。它定义了客户端必须在多长时间内默认1分钟完成认证握手比如输入密码。如果客户端网络极慢或者恶意拖延这个机制可以防止它长时间占用一个连接资源而不登录。对于内网稳定环境这个值可以适当调大对于公网或不可信网络环境保持较小值甚至更小是安全的。ssl及相关参数是保障数据传输安全的基石。只要你的数据需要跨网络传输尤其是经过公网或不可信的内网区域就必须启用SSL。开启ssl on只是第一步后续的配置才是关键ssl_ciphers指定加密算法套件。默认值ALL:!ADH:!LOW:!EXP:!MD5:STRENGTH是一个比较安全的策略它启用了所有算法但排除了不安全的如ADH匿名Diffie-Hellman、低强度算法、出口级算法和MD5并优先选择强度高的。除非有特别的合规要求否则建议保持默认。ssl_cert_file,ssl_key_file,ssl_ca_file这三个文件构成了SSL的信任链。server.crt和server.key是服务器的证书和私钥。ssl_ca_file是颁发服务器证书的CA证书权威机构的根证书。如果启用客户端证书验证双向SSL客户端也需要提供由同一CA签发的证书。重要提醒这些文件的路径是相对于数据目录的且千万不要放在数据目录的子目录下。因为在进行主备切换、数据库重建等操作时备机可能会清理数据目录的子目录导致证书丢失引发SSL连接故障。我吃过这个亏最好的做法是放在数据目录的平级或完全独立的目录然后在配置中使用相对路径../certs/server.crt或绝对路径。localdomain_ssl_mode这个参数挺有意思它控制同地域比如同一个可用区或数据中心的节点间通信是否优先使用SSL。默认是1启用。即使在内网启用SSL也能防止窃听和中间人攻击虽然会带来一点CPU开销但在现代硬件上这点开销对于安全收益来说是值得的。3.2 密码安全策略从复杂度到防爆破弱密码是数据库被攻破的最常见原因之一。GaussDB内置了一套完善的密码策略参数。password_policy默认是1启用密码复杂度检查。它会强制要求密码包含大小写字母、数字和特殊字符并且有最小长度限制。强烈不建议将其设为0关闭此功能。我见过有开发图省事关了策略结果用了123456当数据库密码上线没多久就被扫库了。password_reuse_time和password_reuse_max防止密码循环使用。reuse_time60表示新密码不能是60天内用过的密码。reuse_max0默认表示不检查历史次数。你可以根据安全等级调整比如金融系统可以设置reuse_time90和reuse_max5要求密码在90天内不能重复且不能是最近用过的5个密码之一。failed_login_attempts和password_lock_time这是防暴力破解的“自动锁”机制。failed_login_attempts10意味着连续10次密码错误这个用户账户就会被自动锁定。password_lock_time1代表锁定1分钟单位是天1代表1天这里注意原文默认值是1天实际配置需看清单位。这两个参数必须都为正数才生效。对于高安全场景可以设置更严格的策略比如failed_login_attempts5,password_lock_time0.5锁定12小时。ip_not_locked参数可以设置白名单IP避免运维人员自己把自己锁在外面。password_encryption_type密码在系统表中存储的加密方式。默认是1使用SHA256加密。绝对不要为了兼容老旧客户端而改回0MD5MD5算法已被证明可碰撞非常不安全。3.3 高级安全与钱包目录wallet_directory参数指向一个“电子钱包”的目录用于安全地存储一些敏感信息比如透明数据加密TDE的密钥。配置这个参数时路径长度不能超过1024字符否则会被截断导致错误。通常保持默认的pg_wallet即可它会放在数据目录下。你需要确保这个目录的权限严格受限只有数据库运行用户有读写权限。安全配置的实战心得是不要一次性把所有策略调到最严尤其是登录失败锁定策略。可以先在测试环境模拟应用的各种连接场景比如重启时连接池瞬间重试确保不会误触发锁定影响业务。然后采用“逐步收紧”的策略先在非核心业务库上线观察再推广到全站。同时所有安全配置的变更都必须有回滚方案和应急联系人毕竟把合法用户挡在门外的“安全”也是故障。