前两天一个朋友找我吐槽，说他公司新来的运维工程师，花了一整天装MySQL，结果装完连不上，发现是配置文件里端口写错了。这种事我见得太多了，说白了很多人在服务器上装数据库，还是停留在“装完能跑就行”的阶段。但问题是，数据库这玩意儿，装得顺不顺手，直接决定了后面几个月甚至几年你维护的时候是舒舒服服还是天天想骂娘。我干这行十几年，踩过的坑比饭馆里的苍蝇还多，今天就跟你聊聊，服务器上装数据库，到底该怎么干，才能不给自己埋雷。
很多人一上来就想着“apt-get install mysql-server”，或者下载个RPM包直接敲命令。这做法对测试环境没问题，但放在生产服务器上，简直就是给自己找麻烦。生产环境的数据库安装，第一步不是敲键盘，而是搞清楚你的业务需求。你得先想明白：这个数据库要跑什么类型的负载？是OLTP那种高频小查询，还是OLAP那种吃内存的批处理？数据量多大？并发量多少？这些信息直接决定了你选什么版本、什么存储引擎、什么配置参数。别小看这一步，我见过太多人装完才发现MySQL 5.7不支持某些新特性，或者InnoDB的缓冲池设小了导致性能崩盘。所以，开工之前，先花半小时把需求理清楚，比后面加班改配置强一百倍。
选好了版本，接下来就是安装方式。市面上主流的安装方式有三种：源码编译、二进制包解压、包管理器安装。很多人图省事，直接选包管理器，但生产环境我强烈建议用二进制包。为啥？因为包管理器装出来的东西，路径、版本、依赖都被锁死了，你没法灵活控制。比如你apt装个MySQL，它默认给你塞到/usr/bin，日志扔/var/log，数据存/var/lib/mysql。万一哪天你想换块硬盘，或者调整目录权限，改起来麻烦得要死。二进制包就不一样，解压到指定目录后，所有路径你说了算，日志、数据、配置文件全都能按你想要的来。而且，二进制包不依赖系统库版本，迁移到另一台服务器，解压过去就能跑，省心得多。当然，编译安装也有它的好处，比如能定制编译参数，但除非你有特殊需求，否则没必要自己造轮子。
安装完成后，大多数人会直接启动服务，然后开始建表。但我劝你，先别急，最重要的一步还没做——配置优化。默认的配置文件，比如MySQL的my.cnf，通常是给通用场景用的，性能只能算及格。你得根据服务器硬件和业务场景去调优。比如内存：innodbbufferpoolsize这个参数，默认只有128M，但你服务器有64G内存，设成40G-50G才合理。再比如连接数：maxconnections默认151，如果你的应用是微服务架构，几百个服务同时连，这个值肯定不够。还有日志：binlog要不要开？开的话保留几天？这些都得想清楚。我见过一个案例，某电商公司双十一当天，数据库因为binlog暴增把磁盘写满了，直接挂了两个小时，损失几百万。调优不是炫技，是保命。
配置调完了，接下来是安全设置。很多人觉得，数据库装在内网，没暴露外网，安全就不用太操心。但现实是，内网也不安全。比如默认的root用户，密码是空或者弱口令，攻击者只要扫到你的端口，就能直接登进去。还有，默认端口3306，你如果没改，别人扫一下就知道你用的是MySQL。更别提有些版本还有已知漏洞，比如MySQL的旧版本存在权限提升漏洞，低权限用户能拿到root权限。所以，装完之后，第一步就是改root密码，用强口令，最好20位以上。第二步，删掉默认的test数据库和匿名用户。第三步，修改默认端口，或者用防火墙限制来源IP。如果条件允许，还可以启用SSL加密通信。别嫌麻烦，这些操作花不了十分钟，但能挡掉90%的低级攻击。
安全搞定了，还得考虑备份和恢复。备份这件事，99%的人都知道重要，但真正做好的不到10%。很多人备份就是写个crontab，每天凌晨dump一次，然后扔到本地磁盘。但你想过没有，如果服务器硬盘坏了，备份文件也跟着一起凉了。所以，备份一定要遵循“3-2-1”原则：至少3份副本，存在2种不同的介质上，其中1份在异地。比如，本地存一份全量备份，远程服务器再存一份增量备份，云存储再放一份。工具方面，MySQL可以用mysqldump或XtraBackup，PostgreSQL有pgdump和pgbasebackup。而且，备份完一定要做恢复演练，别等到真出事了才发现备份文件损坏。我同事之前公司，备份跑了两年没出问题，结果一次误删表，恢复时发现备份文件是坏的，只能从binlog慢慢追，追了一整天才恢复一半数据，老板差点把他开了。
别忘了监控和日志。数据库装好只是个开始，运行起来才是真正的考验。你得知道它什么时候会出问题，不然等用户投诉才发现，就太晚了。监控指标主要看几个：CPU使用率、内存占用、磁盘IO、连接数、慢查询数。工具方面，Prometheus+Grafana是标配，能实时展示数据库状态。日志也要配置好，MySQL的慢查询日志一定要开，设置longquerytime为1秒甚至更低，这样能抓到那些拖慢性能的SQL。还有个容易被忽略的点——错误日志。数据库启动失败、表损坏、主从同步中断，这些信息都会记在错误日志里。很多运维出了问题，第一反应是重启服务，但重启完问题还在，因为根本没看日志。装完数据库，花半小时把监控和日志体系搭起来，比事后救火强一百倍。
