咖啡网站设计建设,网站推广网络推广方,建筑资格证书查询官网,wordpress 伪静态 页面背景#xff1a;项目使用pg一主一从#xff0c;因慢sql导致查询慢#xff0c;所以想从原本的4核加到16核#xff0c;联系好运维后#xff0c;打算先从从库开始操作#xff0c;机器上的pgsql都正常关闭#xff0c;然后停止#xff0c;关机#xff0c;扩容一切都很顺利项目使用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点收工回家。 总结一句话“生产数据不备份用时两行泪
