我刚入行那会儿，干过一件蠢事。公司要上一套新系统，我花了两天时间，从操作系统装起，一步一步把MySQL跑了起来，心想这下稳了。结果第二天一早，服务器直接卡死，连SSH都登不上去。查了半天才发现，我图省事，用的全是默认配置，数据文件就放在跟系统盘一个分区，日志文件也没单独规划。那天我蹲在机房，看着满屏的I/O错误，心里只有一个念头：搭建数据库服务器这事儿，真不是你装个软件就完事了。
很多人觉得，数据库服务器嘛，无非就是装个Linux，配个MySQL或者PostgreSQL，数据往硬盘里一扔，完事。这种想法要不得。数据库服务器跟普通应用服务器最大的区别在于，它对IOPS的敏感度极高，对内存的消耗极大，对网络延迟的要求近乎苛刻。你随便找个云主机，装个默认系统，跑个默认配置，短期看可能没问题，但只要数据量一上来，或者并发一高，那些被你忽略的细节就会像地雷一样，一个接一个地炸。
先说操作系统选型。不要为了追新而装最新的发行版，也别图省事装个桌面版。CentOS 7虽然已经停止维护了，但很多生产环境还在用它的替代品Rocky Linux或AlmaLinux。Ubuntu Server 20.04 LTS或者22.04 LTS也完全够用。关键是内核版本要稳定，文件系统要选对。XFS是很多DBA的首选，它对大文件、大并发场景的支持比ext4要好。千万别用btrfs或者ZFS，除非你真有特殊需求，否则它们带来的压缩、快照功能，在数据库场景下反而可能成为性能瓶颈。
磁盘分区这块，很多人会犯一个低级错误：把根目录、数据目录、日志目录全塞在一个分区里。你想象一下，数据库写日志的时候，如果跟数据文件抢同一块磁盘的I/O，那性能损耗是成倍的。正确的做法是，至少分三个独立分区：系统分区（/）、数据分区（/data）、日志分区（/log）。有条件的话，最好用三块不同的物理磁盘，或者云上的三块独立云盘。数据盘用SSD，日志盘用NVMe，系统盘用普通SSD就行。这样即便数据盘写满了，系统还能正常登录进去排查问题，不至于直接宕机。
内存配置是个玄学。很多人以为数据库服务器内存越大越好，于是直接往服务器里插满了内存条，然后数据库配置里也把缓冲区设得极大。但你得知道，操作系统本身也需要内存来缓存文件系统。如果数据库进程把内存吃光了，操作系统连page cache都分配不到，那你的磁盘I/O就会暴涨，因为每次读写都得直接落盘。以MySQL为例，innodbbufferpoolsize建议设为物理内存的70%左右，剩下30%留给操作系统和其他进程。PostgreSQL的sharedbuffers更保守，一般设到物理内存的25%就够了，因为它还依赖操作系统的page cache来做缓存。
网络配置容易被忽略。很多人装完数据库，直接开个默认端口，然后用root账号远程登录，密码设个123456。这跟把家门钥匙挂在门上有什么区别？数据库服务器应该放在内网，只允许应用服务器通过特定端口访问。如果必须暴露在外网，那一定得做IP白名单，并且禁用root远程登录，创建一个权限最小的应用账号。另外，千万别忽略TCP keepalive和timeout的设置，很多数据库连接断开的问题，源头都是这些默认参数没调。比如MySQL的wait_timeout，默认为8小时，如果你的应用有大量闲置连接，这些连接会一直占用内存，直到超过8小时才被释放。
备份策略是个老生常谈的问题，但也是踩坑重灾区。我见过太多人，数据库跑了大半年，从来没想过备份，直到某天硬盘坏了，才哭着找数据。备份不是定时跑个mysqldump就完事了。你得考虑备份文件的存放位置，是存在同一台服务器上，还是传到远程存储？如果跟数据文件在同一块硬盘上，那硬盘坏了，备份也跟着没了，这备份等于没做。还要考虑备份窗口，数据量大到一定程度，mysqldump会锁表，影响线上业务。这时候就得用物理备份工具，比如Percona XtraBackup，它能在不锁表的情况下做热备。另外，备份文件得定期做恢复测试，不然你真不知道备份文件是不是损坏的。
性能压测这一步，很多人觉得可有可无，或者随便跑个SELECT 1就认为没问题。实际上，压测能暴露出很多你在配置阶段根本想不到的问题。比如，你的磁盘IOPS到底够不够？你的内存分配是否合理？你的网络带宽会不会成为瓶颈？用sysbench或者pgbench，模拟你预期的并发量，跑个半小时，看看各项指标。如果CPU使用率一直飙到100%，那可能是SQL写得不好或者索引没建好。如果磁盘I/O等待时间很长，那可能是磁盘类型选错了或者分区策略有问题。压测完还要看慢查询日志，那些执行时间超过1秒的SQL，你得一个一个排查。
监控告警是一道防线，但很多人把它当成可有可无的装饰。数据库服务器出问题，往往是渐进的，不是突然崩溃。磁盘空间从80%涨到90%，你可能觉得没事。从90%涨到95%，你还在犹豫要不要清理。涨到98%，数据库直接停止写入，这时候你才发现问题。所以，磁盘使用率超过85%就要告警，超过90%就得立即处理。连接数、慢查询数、主从延迟、死锁次数，这些指标都得监控起来。用Prometheus加Grafana，或者Zabbix，选一个你熟悉的工具，把告警规则配好。别等到用户反馈系统卡了，你才想起来去查数据库。
说一句，搭建数据库服务器，从来不是一次性的工作。你装好系统、配置好参数、跑通压测、配好监控，这只是万里长征的第一步。随着业务增长，数据量翻倍，访问模式变化，那些当初看似合理的配置，可能很快就会变成瓶颈。所以，保持敬畏，定期复盘，不要觉得数据库稳定运行半年就万事大吉了。那些你偷懒没做的步骤，迟早会以生产事故的方式，回来找你算账。
