Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-7635

update defaults and simplify mysqld config parameters

Details

    • 5.5.51 & 10.2.2, 10.2.2-1, 10.2.3-1, 10.2.3-2, 10.2.4-4, 10.2.4-1, 10.2.4-5, 10.0.29

    Description

      Poor MySQL has received some negative feedback over the years 1 2. As entertaining as it is watching and listening to developers struggle and whine, I think it's about time we changed some of the defaults and made the config easier to understand.

      Oracle are working on changing more defaults in 5.7 3 4 5, I think we should too.

      Something else they have done, is to radically change the simplicity of the default server config file, /etc/my.cnf:
      https://raw.githubusercontent.com/mysql/mysql-server/5.7/support-files/my-default.cnf.sh

      It's quite clear there, the sql_mode has been set, which will satisfy most developers and users looking for an ACID compliant database with little tweaking, and a rough note on increasing or decreasing RAM needed for InnoDB. MariaDB now probably needs something similar for Galera, CONNET and TokuDB.

      1. http://sql-info.de/mysql/gotchas.html
      2. http://blog.ionelmc.ro/2014/12/28/terrible-choices-mysql/
      3. http://www.tocker.ca/2015/01/23/proposal-to-change-additional-defaults-in-mysql-5-7.html
      4. http://www.tocker.ca/2015/01/14/proposal-to-change-replication-and-innodb-settings-in-mysql-5-7.html
      5. http://www.tocker.ca/2015/02/24/proposal-to-change-additional-defaults-in-mysql-5-7-february-edition.html

      Proposed new defaults:

      innodb_autoinc_lock_mode            = 2         (was: 1)
      innodb_buffer_pool_dump_at_shutdown = ON        (was: OFF)
      innodb_buffer_pool_dump_pct         = 25        (was: 100)
      innodb_buffer_pool_load_at_startup  = ON        (was: OFF)
      innodb_checksum_algorithm           = CRC32     (was: INNODB)
      innodb_file_format                  = Barracuda (was: Antelope)
      innodb_file_format_max              = Barracuda (was: Antelope)
      innodb_large_prefix                 = ON        (was: OFF)
      innodb_log_compressed_pages         = ON        (was: OFF)
      innodb_purge_threads                = 4         (was: 1)
      innodb_strict_mode                  = ON        (was: OFF)
       
      binlog_annotate_row_events          = ON        (was: OFF)
      binlog_format                       = MIXED     (was: STATEMENT)
      group_concat_max_len                = 1M        (was: 1025)
      lock_wait_timeout                   = 86400(1day)(was: 1year)
      log_slow_admin_statements           = ON        (was: OFF)
      log_slow_slave_statements           = ON        (was: OFF)
      log_warnings                        = 2         (was: 1)
      max_allowed_packet                  = 16M       (was: 4M)
      replicate_annotate_row_events       = ON        (was: OFF)
      slave_net_timeout                   = 60        (was: 3600)
      sync_binlog                         = 1         (was: 0)
      aria_recover                        = FORCE, BACKUP (was: NORMAL)
      myisam_recover_options              = FORCE, BACKUP (was: OFF)
      

      Attachments

        Issue Links

          Activity

            I disagree, rather strongly. Keeping binary logs can be crucially important for various reasons. Removing them automatically by default can be a disaster, which the user will only find out when it's too late. Size does not matter here – the activity can be low, the disk can be large, and any reasonable real-life setup will monitor the disk status anyway, and the admin will make the decision about binary logs if it comes to that.

            elenst Elena Stepanova added a comment - I disagree, rather strongly. Keeping binary logs can be crucially important for various reasons. Removing them automatically by default can be a disaster, which the user will only find out when it's too late. Size does not matter here – the activity can be low, the disk can be large, and any reasonable real-life setup will monitor the disk status anyway, and the admin will make the decision about binary logs if it comes to that.
            danblack Daniel Black added a comment -

            Fair call. disk monitoring is a much better approach.

            danblack Daniel Black added a comment - Fair call. disk monitoring is a much better approach.
            wlad Vladislav Vaintroub added a comment - - edited

            I propose (discussed with elenst in the past while analyzing MDEV-11226)

            thread_pool_max_threads=65535

            Usually, there should not really be an upper bound to thread count by default, but DBAs who know their workload well, might want set it.
            had a patch for this variable myself, but since you're already at it, and chance the same places, maybe it should go into this one.

            wlad Vladislav Vaintroub added a comment - - edited I propose (discussed with elenst in the past while analyzing MDEV-11226 ) thread_pool_max_threads=65535 Usually, there should not really be an upper bound to thread count by default, but DBAs who know their workload well, might want set it. had a patch for this variable myself, but since you're already at it, and chance the same places, maybe it should go into this one.
            elenst Elena Stepanova added a comment - - edited

            nirbhay_c,

            As requested, I've looked at bb-10.2-mdev7635, diff between fd0479ce592e0b7c13d67b5deda62e9090956309 and the current e2d94b684a070b94519cd45e923a3c41267f66c4.

            There are a few suites that haven't been fixed. I've noticed

            • mroonga/* (most important, since it's a part of the default set)
            • jp (also runs in buildbot on fulltest)
            • engines/*

            I expect you're going to adjust them as well.

            Also I have some doubts about innodb_storedproc* tests. Unlike in other tests, here you've kept the strict mode without ignore close, so that it didn't allow data to be loaded, which naturally further caused differences in result sets which were re-recorded. Unless you did it on purpose, maybe it makes sense to restore the test logic.

            Apart from those, it looks mostly fine. I have some technical suggestions/fixes, all of which are pushed into bb-10.2-mdev7635.elenst, see
            https://github.com/MariaDB/server/commits/bb-10.2-mdev7635.elenst

            I intentionally created very itemized commits, so that it was clear which is doing what, and you could pick them up separately (they are mostly independent, except for maybe one or two).
            You only need those that start with "Additional test fixes for MDEV-7635 #N". There are 13 of them now.
            You don't need two others, one of which is to exclude mroonga from defaults (you don't need to merge it as it has to be fixed anyway), and one to disable a test which currently fails on 10.2 (you don't need to merge it either, it's already disabled in 10.2 and will be re-enabled when the problem is fixed).

            Not related to tests directly, I still have some concerns about sync-binlog (see MDEV-11900), and about the new combination of slow-log options which ends up with a warning (see MDEV-11908), I don't think it makes any sense.

            elenst Elena Stepanova added a comment - - edited nirbhay_c , As requested, I've looked at bb-10.2-mdev7635 , diff between fd0479ce592e0b7c13d67b5deda62e9090956309 and the current e2d94b684a070b94519cd45e923a3c41267f66c4. There are a few suites that haven't been fixed. I've noticed mroonga/* (most important, since it's a part of the default set) jp (also runs in buildbot on fulltest) engines/* I expect you're going to adjust them as well. Also I have some doubts about innodb_storedproc* tests. Unlike in other tests, here you've kept the strict mode without ignore close, so that it didn't allow data to be loaded, which naturally further caused differences in result sets which were re-recorded. Unless you did it on purpose, maybe it makes sense to restore the test logic. Apart from those, it looks mostly fine. I have some technical suggestions/fixes, all of which are pushed into bb-10.2-mdev7635.elenst, see https://github.com/MariaDB/server/commits/bb-10.2-mdev7635.elenst I intentionally created very itemized commits, so that it was clear which is doing what, and you could pick them up separately (they are mostly independent, except for maybe one or two). You only need those that start with "Additional test fixes for MDEV-7635 #N". There are 13 of them now. You don't need two others, one of which is to exclude mroonga from defaults (you don't need to merge it as it has to be fixed anyway), and one to disable a test which currently fails on 10.2 (you don't need to merge it either, it's already disabled in 10.2 and will be re-enabled when the problem is fixed). Not related to tests directly, I still have some concerns about sync-binlog (see MDEV-11900 ), and about the new combination of slow-log options which ends up with a warning (see MDEV-11908 ), I don't think it makes any sense.
            nirbhay_c Nirbhay Choubey (Inactive) added a comment - thread_pool_max_threads=65535 https://github.com/MariaDB/server/commit/def258061b884df91624562c27c818f9d1fa2d5c

            People

              nirbhay_c Nirbhay Choubey (Inactive)
              mathnode Richard Bensley
              Votes:
              3 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.