背景：项目使用pg一主一从，因慢sql导致查询慢，所以想从原本的4核加到16核，联系好运维后，打算先从从库开始操作，机器上的pgsql都正常关闭，然后停止，关机，扩容一切都很顺利，启动后pg正常启动，不好事情就开始要发生了

1、停止后看app发现已经开始报错了，然后查原因，发现pgsql开启了一主一从，synchronous_commit默认参数是on，表示使用同步提交，即事务提交后等待至少一个副本写入磁盘后才返回成功。而从库因停止导致主库一直等从库响应引发的问题，然后马上把从库启起来。

2、接着发现注册中心nacos连的mysql也在这台从库上，mysql没有正常关闭，然后又因为mysql也是主从同时开启了binlog，导致非正常关闭，把mysqld.pid文件丢失了，就改my.cnf的配置，改目录然后重启。mysql好了。折腾了有一会。到这里以为一切顺利的时候开始准备操作主库。

3、主库也是一样的操作，然后同时把postgresql.conf中的synchronous_commit修改后，synchronous_commit有以下几个选项，本次直接改的是local

off：表示不使用同步提交，即事务提交后不会等待任何副本写入磁盘。这是默认值。
on：表示使用同步提交，即事务提交后等待至少一个副本写入磁盘后才返回成功。
remote_write：表示使用同步提交，但只等待至少一个远程副本写入磁盘后才返回成功。如果没有远程副本，则等待本地副本写入磁盘。
remote_apply：表示使用同步提交，等待至少一个远程副本应用日志后才返回成功。如果没有远程副本，则等待本地副本应用日志。
local:选项不需要等待远程副本写入磁盘或应用日志。这使得它比其他同步提交选项更快，但也更容易丢失数据，因为只有本地副本写入磁盘后才返回成功。因此，local选项适合于对数据丢失有一定容忍度的应用程序

以为到这里就没啥问题，
4、开始正常起服务，起着突然发现报错了，我们服务有授权，这个时候只有一个节点，但提示已经慢了，心想不可能啊，一看配置，怎么读的是测试环境的授权。然后改成了生产的就继续起。
5、接着起发现少字段，心里想，不对啊，这项目已经跑了2-3年了，怎么可能会有这种问题呢，然后就开始看代码，加一个字段，
6、接着又继续起，还是报错，突然感觉不妙，看了一些数据表，全部没了，这时犹如晴天霹雳，所有人心里开始慌了，想着没有操作什么啊，难道运维干了其它事情？然后联系运维，问有没有做额外的操作，运维说：“没有”,，又问是不是有磁盘没有挂载，运维说：“这个不清楚”，然后就挂了电话。听到运维这样说，我和同事都已经双脚开始颤抖了，数据库又没有备份，难道职业生涯就要到此结束了吗？还是生产数据，跑了2-3年，此时app也已经停了4-5个小时了。（提醒，生产数据库一定要做备份）
这个时候同事说，之前遇到过机器重启后，linux自动重置系统，把在做的人全部吓了一跳，如果这样的话就完了。
解决方案即将迎来反转：
我们回想一下整个的操作，重复上述的操作的描述后。提议开始分2步走，
1、继续排查原因，看看什么原因，数据能不能恢复。
2、做最坏的打算，周末两天连续扛，因为我们的数据都是通过Kafka发送的，可以修改offset从头消费。还有一些其它配置拉各个系统对齐。
提议完成后，给领导先汇报了一下这个情况，然后说了我们的解决方案，就开始干起来。

我去到pg的数据目录一看，时间是系统重启的时间，我想不对劲啊，人为是不可能这样的呀，就通过history查看机器历史执行命令。机器就1000行左右的历史，一直翻翻翻，
翻到200行的时候，一个mount命令映入眼前。“卧槽，历史有手动挂载过磁盘”，我一声大喊，这个时候边上的同事都飞奔过来，
边上的同事说到看一下/etc/fstab （图片为测试环境）
文件是不是没有自动把磁盘挂载回去，一看果然是，然后lsblk（图片为测试环境）

查看系统挂载的磁盘。这个时候全部开始骂娘，这运维初始化机器的时候怎么回事，有磁盘挂载还不重启的时候自动挂载回去。
大家也就松了一口气，然后准备开始操作恢复
1、原本起的服务，mysql、pg停了。
2、先起pg看数据能不能正常恢复。
3、在恢复mysql。
4、恢复系统。
当执行完挂载命令后，pg重启数据回来了，悬着的心就放下来了。接着把之前mysql的my.cnf还原（操作重要文件时都先备份！！！）在恢复。所有的数据都回来了。
叹了一口气，就慢慢恢复系统，同时在/etc/fstab
增加了系统重启自动挂载磁盘的配置，最后在给领导同步了一下情况。至此凌晨2点收工回家。
总结一句话：“生产数据不备份，用时两行泪！！