The meaning of the main parameters of the MariaDB configuration file

Configuration file my-innodb-heavy-4G.cnf

The main parameters

  • password: the password when the mysql client connects to mysql
  • port: mysql listening port, the default is 3306
  • skip-networking: This option is not turned on by default. After it is turned on, only local connections can be made, and other hosts cannot connect to this database through the network
  • back_log: is the number of connections that the operating system can keep in the queue. If the connection rate is high or a "connection refuse" error occurs when connecting to the database, you can increase the value of this parameter. But if you set back_log to be higher than the number of files that the operating system can open, it will have no effect. You can use the command "more /proc/sys/fs/file-nr" to view the number of open system files. The command will output 3 parameters, which represent the number of allocated file handles, the number of used file handles, and the maximum number of file handles. Number (back_log cannot be greater than this value)
    Insert picture description here
  • external-locking: External locking, which is not turned on by default, but if it is turned on, if each process wants to access the data table, it must wait until the previous process completes the operation and unlocks, then the database service will often be in a state of waiting for unlocking, so in Enabling this parameter for single database service will degrade database performance. But if multiple servers use the same database directory, then each server must enable external-locking.
  • max_allowed_packet: The maximum size of the request packet that the service can handle and the maximum request that the service can handle. When the database client or mysqld service receives a packet larger than max_allowed_packer bytes, it will issue a "packet too large" error and close the connection. For some clients, if the communication information packet is too large, during the execution of the query, it may encounter a "lost connection with the MySQL server" error. If you plan to handle large packets, you must increase this variable on the client and server.
  • max_heap_table_size: The maximum capacity allowed by an independent memory table. Prevent accidental creation of a large memory table causing exhaustion of all memory resources.
  • read_buffer_size: The random read buffer size of mariadb. When rows can be read in any order (for example, in sort order), a random read buffer will be allocated. When sorting and querying, the database will scan the buffer first to avoid disk search and improve the query speed. If you need to sort a large amount of data, you can increase the value appropriately. But mariadb will allocate buffer space for each client connection, so you should try to set this value appropriately to avoid excessive memory overhead.
  • query_cache_size: query buffer, often used to buffer the results of SELECT and will not execute the same query next time and return the result directly. If the same query is always done during data operations and the database table is rarely modified, open the query Buffering can greatly increase server speed.
  • log_warnings: print out warnings to the error log file. If you have any problems with MySQL, you can open the warning log and carefully review the error log to find out possible causes.

Parameters of database storage engine InnoDB and MyISAM

The difference between the database storage engine InnoDB and MyISAM: MyISAM type does not support advanced processing such as transaction processing, while InnoDB does. The MyISAM type table emphasizes performance, its execution speed is faster than the InnoDB type, but does not provide transaction support, and does not support foreign keys. InnoDB provides transaction support and advanced database functions such as foreign keys, and an engine that supports transaction security. Supporting foreign keys, row locks, and transactions are his biggest features. If you perform a large number of select and insert MyISAM is more appropriate, if there is a large number of updates and inserts, it is recommended to use InnoDB, especially for multiple concurrency and high QPS.

About MyISAM settings

  • key_buffer_size: The size of the keyword buffer, generally used to buffer the index of MyISAM table. It cannot be set greater than 30% of the available memory, because part of the memory is also used by the OS to buffer row data. Because it will also be used by internal temporary disk tables, even when MyISAM tables are not applicable, 8-64M memory is still required.
  • bulk_insert_buffer_size: MyISAM uses a special tree-like cache to make burst inserts (such as INSERT… SELECT, INSERT… VALUES (…), (…), …, and LOAD DATA INFILE, etc.) faster. This variable limits the number of bytes of the buffer book in each process. Setting it to 0 will turn off this optimization. For optimization, do not set this value greater than "key_buffer_size". This buffer will be allocated when burst insertion is detected.
  • myisam_sort_buffer_size: This buffer is allocated when MySQL needs to rebuild indexes in REPAIR, OPTIMIZE, ALTER and LOAD DATA INFILE to an empty table. This is allocated in each thread. So be careful when setting large values.
  • myisam_max_sort_file_size: The maximum temporary file size allowed when MySQL rebuilds the index. If the file size is larger than this value, the index will be created through the key-value buffer (slower)

About InnoDB settings

  • innodb_additional_mem_pool_size: The additional memory pool is used by InnoDB to store metadata information. If InnoDB needs more memory for this purpose, it will start requesting memory from the OS. Since this operation is fast enough on most modern operating systems, there is generally no need to modify this value. The SHOW INNODB STATUS command will display the currently used quantity.
  • innodb_buffer_pool_size: Unlike MyISAM, InnoDB uses a buffer pool to store indexes and original data. The larger the value set here, the less disk I/O is required to access the data in the table. On an independent database server, you can set this variable to 80% of the server's physical memory size
  • innodb_data_file_path: InnoDB saves data in one or more data files as a table space. If you only have the logical drive to save data, a single auto-increment file is good enough. In other cases, it is best to have one file per device.
  • innodb_write_io_threads, innodb_read_io_threads: The number of IO threads used to synchronize IO operations.
  • innodb_thread_concurrency: The number of threads allowed in the InnoDB core. The optimal value depends on the scheduling method of the application, hardware, and operating system. Too high a value may lead to thrashing of threads.
  • innodb_log_file_size: The size of each log file in the log group. The total size of the log files should be 25%-100% of the buffer pool size to avoid unnecessary buffer pool refresh behavior on log file overwriting
  • InnoDB_lock_wait_timeout: How long an InnoDB transaction should wait for a lock to be approved before being rolled back. InnoDB automatically detects transaction deadlocks in its own lock table and rolls back the transaction. If the LOCK TABLES instruction is used, or a transaction-safe storage engine other than InnoDB is used in the same transaction, a deadlock may occur and InnoDB cannot notice. In this case, the timeout value is very useful for solving this problem. helpful.

Configuration parameters related to master-slave replication

  • server-id: The unique service identification number of each database. In master-slave replication, the server-id number between master and slave cannot be the same, otherwise an error will be reported. This parameter needs to be set on both master and slave.
  • log-bin: Turn on the binary log function, because the principle of master-slave replication is to record the operation of the master in the binary log binlog, and then the slave I/O thread reads the binlog of the master server and records it to the relay log relay-log In the master-slave replication process, the slave's SQL thread achieves the purpose of synchronization with the master by executing the operations in the relay log. Therefore, this function must be turned on during the master-slave replication process.
  • binlog_cache_size: The size of the cache held by binlog in order to record the SQL state in a transaction. If you need to use large, multi-declared transactions frequently, you can increase this value to get greater performance. All the state from the transaction will be buffered in the binlog buffer, and then written into the binlog once after submission. If the transaction is larger than this value, a temporary file on the disk will be used instead.
  • binlog_format: Set the format for recording the binary log. There are three formats: statement-based, row-based, and mixed. When set to statement, the sql statement will be recorded in the binlog. There is only a need to record the sql statement that will modify the data in the binlog, which reduces the amount of binlog logs, saves I/O, and improves performance. The disadvantage is that in some cases, the data in the master and slave nodes will be inconsistent. Setting it to row means that mysql master decomposes SQL statements into statements based on row changes and records them in the binlog, that is, only records which data has been modified and what is modified. The advantage is that there will be no problems with stored procedures, functions, trigger calls or triggers that cannot be copied correctly under certain specific circumstances. The disadvantage is that a large number of logs will be generated, especially when the table is modified, the log will increase sharply, and the binlog synchronization time will increase. It is also not possible to obtain the executed SQL statements through binlog analysis, only the data changes that have occurred can be seen. Mixed is a mixture of the above two modes. For general replication, use STATEMENT mode to save to binlog, and for operations that cannot be replicated in STATEMENT mode, use ROW mode to save. MySQL will select the log saving method based on the executed SQL statement.
  • Relay-log: When the slave library needs to turn on the relay-log function, set the position of the relay-log.
  • master-host: The host name of the master. The slave needs to be set to connect to the corresponding master.
  • master-user: the user name used for authentication when the slave connects to the master
  • master-password: The password used for authentication when the slave connects to the master.
  • master-port: master-port: the port the master listens on, the default is 3306
  • read_only: Set the slave to be read-only. Only the user with the supper permission can modify the data on the slave to ensure that the data of the slave will not be arbitrarily changed by other processes.
  • expire_logs_days: This parameter is mainly used to control the master's binary log retention time. If it exceeds the specified time, the log will be automatically deleted.
  • sync_binlog: This parameter is very important to the MySQL system. It not only affects the performance loss caused by binlog to MySQL, but also affects the integrity of the data in mariadb. It controls the synchronization frequency of the binary log and the hard disk. If this parameter is set to 0, it means that MySQL does not control the refresh of binlog, and the file system controls the refresh of its cache. If it is set to a value other than 0, it means that MySQL will call once for each sync_binlog transaction operation. The file system refresh operation refreshes the binlog to the disk. This parameter is set to 1 is the safest, that is, a transaction will be refreshed once, and at most one transaction update will be lost when the system fails, but it will have an impact on performance. Generally, it will be set to 100 or 0, at a cost Consistency to obtain better performance.
  • slave-skip-errors: This parameter can skip the errors of the specified error code and continue to the next step of copying.
  • relay-log-space-limit: This parameter is to prevent the relay log from filling up the disk to set the maximum relay log limit. However, this setting has the situation that the main library crashes and the relay log of the slave library is incomplete. It is not a last resort and is not recommended.
  • binlog-do-db: set on the master database, and set the slave database to only synchronize the specified database. Usage: binlog-do-db = databases
  • binlog-ignore-db: set on the main database, ignore the specified database and not synchronize when setting synchronization. Usage: binlog-ignore-db = database
  • replicate-do-db: Set on the slave database, the setting can only synchronize the specified database. Usage: replicate-do-db = database
  • replicate-do-table: set on the slave database, the setting can only synchronize the specified table of the specified database. Usage: replicate-do-table = database.table
  • replicate-ignore-db: set on the slave database, ignore the specified database and not synchronize when setting synchronization. Usage: replicate-ignore-db = database
  • replicate-ignore-table: In the slave database setting, the specified table of the formulated database is ignored and not synchronized when setting synchronization. Usage: replicate-ignore-table = database.table

Note: When the slave library ignores the settings of the replication database, there are related logs about the master in the relay-log of the slave library, but the slave library is not used.

Slave's master-host, masterr-user, master-password and master-port parameters are not recommended to be changed in the configuration file, because once you choose to change the configuration file to change these parameters, after the first start of replication (even because of a wrong input If you fail to successfully connect to the master for password or other reasons), the slave will create a master.info file, and any subsequent changes to the parameters in this file will be ignored. And because the content in the master.info file will not be automatically loaded, unless the slave service is shut down, master.info is deleted and the slave service is restarted, the parameters of the slave connecting to the master will not be modified. Therefore, it is recommended to use the change master to statement to replace the slave settings after logging in to the database.

Guess you like

Origin blog.csdn.net/xiguashixiaoyu/article/details/107882357