在云服务上自建数据库的坑
随着公司项目的增多我们发现云服务器和数据库、对象存储这类的的成本开始变得很高。尤其突出的是数据库成本,已然超过了直接购买服务器的成本,一个数据库每月有大几千的支出。于是很多项目开始倾向于自己买服务器建数据库服务用于节省成本,然后要填的坑也就多了。
早前写过一篇scp命令把服务器硬盘传输打死导致宕机的文章,当时是因为上传测试环境的代码到服务器的时候没有做压缩处理而是直接使用scp命令上传文件夹。坑爹的是上传代码的时候没有检查代码文件夹的大小没有察觉到.git隐藏目录里面有几十万个小文件导致传输的时候直接干爆了服务器的硬盘IO。确实我也没想到这个项目是N多年多次转手下来的祖传代码,仓库文件有将近10个G。
说回正题,自建数据库后发现除了CPU和内存配置,硬盘IO成了性能短板之一,在自建Redis和MySQL上尤为突出。游戏在大量需要Redis读写的时候遇到了io瓶颈,后来反复优化了代码多次才达到能用的水平。最近遇到了sentry日志服务器频繁爆内存,加了swap虚拟内存卡得一匹,反复复盘后发现个盲点:除了内存确实不够外硬盘的性能实在惨不忍睹。去云服务器控制台看了下挂载的硬盘,IOPS竟然只有可怜的300。之前接手这个项目的大哥创建服务器的时候估计没注意到硬盘读写这个问题,我回想起了刚开始服务器反复宕机凌晨三四点起来debug的恐惧。我们宁愿怀疑自己的技术也没怀疑过服务器的问题。
稍微总结下:
1、自建数据库需要选硬盘性能好一些的配置,推荐IO在3000以上,内存可以稍微大点。
2、做好数据备份,懒一些也可以直接备份服务器镜像或者快照。
3、尽量不要让数据库跑在docker里,非要在docker里跑数据库记得把数据挂载到物理盘。
4、大量的sql插入可以先临时关闭binlog和一些不必要的事务提高导入速度。
5、数据库端口不用默认的常规端口,不要对外开放,非要对外的时候可以设置指定的ip才可以访问,并且加上复杂的密码(9位以上包含字母大小写、数字、特殊字符)。
更多>>