What we do immediately after successful installation of MySQL 5.7 \u00a0for performance and reliability ? We follow a very minimalistic approach for configuring my.cnf \/ MySQL system variables to optimally provision the available system resources and tracing execution of MySQL queries for performance .<\/p>\n

Best practices for configuring my.cnf : <\/span><\/p>\n

\n
• Change only one system variable at a time in my.cnf, This helps in estimating and quantifying the benefits of the change . <\/span><\/li>\n
• Never accept duplicate settings in my.cnf, We recommend using version control to track the system variable changes in my.cnf and always retain the copy \/ backup of my.cnf for restore \/ recovery . <\/span><\/li>\n
• Most of the system variables can be changed at runtime with SET GLOBAL, It is really good because we can rollback if the change is causing the new problem but never forget to note down the changes which you need to add in the my.cnf before next MySQL restart (<\/span>we often see this mistake happening<\/span><\/i>) . <\/span><\/li>\n
• Confirm MySQL system variables are added after [mysqld] in my.cnf . <\/span><\/li>\n
• Never copy my.cf of another server presuming optimal performance, If you have simple queries in MySQL then there is no need to increase sort_buffer_size even if you have 512 GB RAM .<\/span><\/li>\n
• We seriously care about your MySQL reliability above performance so we always recommend setting sync_binlog=1 (presuming binary logging enabled) and innodb_flush_log_at_trx_commit=1<\/b><\/li>\n<\/ul>\n

  The following below are 4 system variables \/ my.cnf values I consider changing immediately after successful MySQL installation for performance and reliability : <\/span><\/p>\n

  \n
  • innodb_buffer_pool_size<\/b> – InnoDB buffer pool caches both data and indexes so always consider setting this value between 50%-75% of available RAM, Does not need to be larger than the database . <\/span><\/li>\n
  • innodb_flush_log_at_trx_commit<\/b> – set this value to “1” (<\/span>default<\/span><\/i>) for maximum reliability and “0\u201d or “2” for less reliability and more performance (<\/span>we don’t recommend this setting<\/b>)<\/span><\/li>\n
  • innodb_log_file_size<\/b> – larger the value less checkpoint flush activity required in buffer pool (this also makes crash recovery slower) so there will be less disk I\/O and benefit in the performance . If your application is write intensive you can set this value to “1 \u00a0GB” (I don’t prefer setting this value too high !!)<\/span><\/li>\n
  • innodb_flush_method<\/b> – You can set this value to “O_DIRECT” to avoid double buffering . <\/span><\/li>\n<\/ul>\n

    Advanced my.cnf configuration in MySQL 5.7<\/strong><\/p>\n

    \n
    • innodb_io_capacity<\/b> and <\/span>innodb_io_capacity_max<\/b> – consider setting these two system variables only if you have a lots of writes all the time (it does not apply for reads \/ SELECTS) \u00a0and use solid-state disks (SSD), We recommend you to benchmark disk throughput (I use sysbench) before setting this value . If you have a server with 1 SSD we recommend innodb_io_capacity “4000” and innodb_io_capacity_max “8000” . \u00a0\u00a0<\/span><\/li>\n
    • Innodb_autoinc_lock_mode<\/b> – Setting innodb_autoinc_lock_mode “2” (interleaved mode) improve the performance of MySQL by not depending on table-level AUTO-INC lock, This makes multi-row insert statements with auto-increment primary key more optimal, This requires binlog_format=ROW or MIXED (and ROW is the default in MySQL 5.7). There may be gaps in the auto-increment values generated by “bulk inserts” , but only if there are concurrently executing “INSERT – like” statements <\/span><\/li>\n<\/ul>\n

      MySQL 5.7 has much better default values<\/strong><\/p>\n

      \n
      • innodb_buffer_pool_dump_at_shutdown<\/b> and <\/span>innodb_buffer_pool_load_startup<\/b> are enabled by default – This records the pages cached in the InnoDB buffer pool when MySQL server is shutdown and shorten the warm-up process at the next restart . <\/span><\/li>\n
      • Innodb_file_per_table<\/b> = ON (DEFAULT)<\/span><\/li>\n
      • Innodb_stats_on_metadata<\/b> = OFF (DEFAULT) , so statistics for queries like SHOW TABLE STATUS OR INFORMATION_SCHEMA.TABLES are not updated,This improves performance and stability of execution plans for queries that involve InnoDB tables .<\/span><\/li>\n
      • QUERY_CACHE_TYPE<\/b> = 0 (DEFAULT) , so it does not acquire the query cache mutex at all and there is reduced overhead in query execution . <\/span><\/li>\n<\/ul>\n

        We use slow_query_log and pt-query-digest for tracing MySQL<\/strong><\/p>\n

        We can dynamically enable slow_query_log and long_query_time (I usually log queries taking more than 1 sec. to execute) for tracing MySQL performance. The pt-query_digest (Percona Toolkit) from Percona makes aggregation of slow_query _log better<\/span><\/p>\n

        pt-query_digest usage :<\/span> <\/em><\/p>\n

        pt-query-digest slow.log<\/span><\/p>\n

        P.S – We have copy of the same post available in SlideShare<\/span><\/a>\u00a0\u00a0and PDF can be downloaded from\u00a0here<\/span><\/a><\/span><\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

        What we do immediately after successful installation of MySQL 5.7 \u00a0for performance and reliability ? We follow a very minimalistic approach for configuring my.cnf \/ MySQL system variables to optimally provision the available system resources […]<\/a><\/p>\n<\/div>","protected":false},"author":10,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,2,15],"tags":[23,99,16],"yoast_head":"\n