MySQL 5.7已经推出多年了,各家针对不同版本也梳理了不同的参数模板。
在实践的过程中,也发现了一些潜在的问题,有些参数开始的时候没有注意到,结果想开启的时候发现是只读变量,要生效只能等待下次重启,这种代价对于数据库高可用维护而言实在是太高了。所以需要提前规划和修正。
在此我不会把所有的参数都列出来,而是列出来最近碰到的一些。
log_timestamps
如果发现有些日志的时间戳不大对劲,其实可以注意以下log_timestamps的参数设置,默认是UTC,我们可以改为SYSTEM,这样就是和系统同步的方式了。这个参数可以在线修改。
extra_max_connections
extra_port
如果数据库运维的时候碰到too many connections,但是你却发现自己也连不上数据库的时候,这种感觉就好比你是一个公交车司机,但是你却挤不上公交车的绝望。如果给我一次机会,就一个连接也可以化解这种困境,什么,要重启,你们DBA怎么就会重启,其实我很担心业务同学这么问。如果一切都在控制中,就不会这么被动了。
这个参数本身不是新参数,在MySQL 5.6.14引入,但是直到MySQL 5.7也是默认没有打开的。所以我们需要关注这两个参数,给自己留点后路。
这个参数是只读变量,要修改后重启数据库生效。
secure_file_priv
这个参数和文件处理有关,在5.7中默认是NULL,即没有开启,这样对于一些导出的SQL语句来说就不可用了。
比如:
select * from user into outfile '/tmp/user.csv'
这个参数如果设置为空串,就和5.6及以下版本兼容了。
secure_file_priv=''
innodb_deadlock_detect
这个参数是我们在版本规划时的一个重点参考参数,这个参数是在5.7.15引进,有了这个参数,对于系统内的死锁灵活开关,很多数据库分支就是还专门定制了类似的功能,当然作为系统优化来说,关闭这个参数对于性能的提升比较明显,作为日常监测问题还是需要的。
slave_parallel_type
slave_parallel_workers
MySQL的并行复制在5.7才算是有了本质的改变,需要注意下从库的这两个参数设置,默认slave_parallel_type不是LOGICAL_CLOCK,我们可以根据服务器的配置来开启相应的并行度。
innodb_purge_threads
innodb_page_cleaners
这两个参数原来是1,需要注意下已有的模板是不是做了固定,5.7中已经是4了。
半同步插件的改进也比较明显,也需要关注下。
此外有几个参数在性能负载不高的数据库环境中根据需要可以使用。
innodb_buffer_pool_size
在线修改buffer pool大小,不建议放心使用,还是负载不高的时候试用。
在线开启GTID
如果可以重启数据库开启,最好是重启开启,在线理论是可行,但是出现问题之后比较麻烦。