MySQL学习分享--机型选择与配置

       由于长期以来，一直忙于日常的工作，自身的学习和提高有所懈怠，最近越发明显感到今年的成长和进步幅度较上年有所降低。因此，从今天开始，坚持非工作时间，潜心学习和研究一些技术，每周汇总一下学习成果，一方面提高自己的技术能力和技术深度，另一方面分享给大家，互相交流。

1、《Inexpensive SSDs for Database Workloads》

       随着SSD的成本不断降低，数据库机型如何选择以及如何更好的利用SSD。文中指出，对于之前担心SSD的写寿命问题，现在来看完全没有必要担心，在过保期内，完全不会成为问题。而在选择SSD的容量和选型时，需要根据业务的DB压力情况来选择，SSD最终会降低机器的IO压力，整体性能。
       在使用SSD的使用方面，文中指出从应用和数据库层面来优化，减少对SSD的写入，更好的保护和延长SSD的寿命。值得注意是：
       1）DoubleWrite数据单独存放，并放在HDD上。DoubleWrite单独存放在以下内容中介绍，存放在HDD上，是由于DoubleWrite是顺序读写。
       2）事务日志存放在HDD上。原因也是顺序读写，使用HDD和Raid卡cache即可。
       3）binlog日志存放在HDD上。binlog的读写也是顺序的，使用HDD即可。
       4）临时空间建议使用tmpfs，即系统的/tmp目录。临时目录写入频繁，且顺序读写较多。
       5）BufferPool增大。这样可以提高内存命中率，减少磁盘IO。
       6）innodb事务日志增大。SSD的读写性能，可以减少恢复的时间。
       7）innodb使用压缩。通过压缩，减少写入的数据量。
       8）使用高压缩比的存储引擎。更高的压缩比，可以更大程度的减少写入的数据量。
       从个人角度来看，SSD的成本会高一些，但是由于提高了单机的性能，会减少机器的数量和机柜成本投入、以及运维成本，对于规模化运维来说，的确是利大于弊。SSD的使用方面，大多数可以值得借鉴，但有些需要根据自己的需求进行选择。例如：在单机多实例的情况下，连续IO操作也变成随机IO，放在HDD对性能的影响较大，这些在统一化部署过程中，很多都尝试并付出了惨痛的教训。

2、《Configuration of the Doublewrite Buffer》

       MySQL引入DoubleWrite主要是为了避免BufferPool中的数据部分写入到磁盘，而导致无法数据恢复的问题。正常情况下，DoubleWrite引入会影响5%~10%的性能损失。然而，在写入压力较大时，写入DoubleWrite就会与BufferPool的随机写入产生竞争，性能影响就会加剧。
       Percona Server引入DoubleWrite独立文件（参数innodb_doublewrite_file），从共用表空间中分离出来。由于DoubleWrite写入是顺序的，官方建议使用HDD存放，并且最好存放在独立磁盘空间下，也可以与redo日志放在相同磁盘下。
       个人认为，目前情况下，DoubleWrite不会造成很大的性能损失，并且如果系统文件层能够保证数据完整性的话，可以禁用DoubleWrite。此外，该参数的引入，还需要充分的性能测试和验证。

参考资料

1、《Inexpensive SSDs for Database Workloads》http://www.mysqlperformanceblog.com/2013/10/03/inexpensive-ssds-database-workloads/
2、《Configuration of the Doublewrite Buffer》