InnoDB and MyISAM
Innodb isolation level principle to achieve
InnoDB master and backup replication
1. mysql and Innodb files
1. Configuration file my.cnf: configure the parameters of mysql, view mysql parameters through show VARIABLES like '%connect_timeout%'
2 . Error log: The error log file records the startup, operation, and shutdown of MySQL.
mysql> show variables like 'log_error'; +---------------+-----------------+ | Variable_name | Value | +---------------+-----------------+ | log_error | ./mysql-err.log | +---------------+-----------------+ 1 row in set (0.01 sec)
3. Slow query log: When MySQL starts, a threshold is set, and all SQL statements whose running time exceeds this value are recorded in the slow query log.
long_query_time : Set the threshold of slow query, SQL exceeding the set value will be recorded in the slow query log, the default value is 10s
slow_query_log: Specify whether to enable the slow query log
log_slow_queries: Specify whether to enable the slow query log (this parameter requires Replaced by slow_query_log, for compatibility preservation)
slow_query_log_file: Specify the storage location of the slow log file, which can be empty, the system will give a default file host_name-slow.log
min_examined_row_limit: The query check returns less than the SQL specified by this parameter will not be Record to slow query log
log_queries_not_using_indexes: Whether the slow query log that does not use the index is recorded to the index
log_throttle_queries_not_using_indexes: Indicates the number of SQL statements that are recorded to the slow log and not using the index per minute. The value defaults to 0, which means no limit. In the production environment, if no index is used, such SQL statements will be frequently recorded in the slow log, resulting in the continuous increase in the size of the slow log file. Therefore, the DBA can configure this parameter through this parameter.
4. Query log: The query log records information about all requests made to the MySQL database, regardless of whether these requests were executed correctly.
5. Binary log: The binary log records all operations that make changes to the MySQL database, but excludes operations such as SELECT and SHOW, which do not modify the data itself. It can be used for data recovery, primary and secondary replication, and database auditing .
max_binlog_size: specifies the maximum size of a single binary log file. If this value is exceeded, a new binary file will be generated.
binlog_cache_size: Specifies the size of the binary cache, all uncommitted binary logs will be recorded in a cache, and the binary log in the cache will be directly written to the binary log file when the transaction is committed.
sync_binlog : Specifies the cache synchronization strategy. The default system setting is sync_binlog=0.
0: After the transaction is committed, MySQL does not refresh the information in the binlog_cache to the disk without performing disk synchronization instructions such as fsync, and lets Filesystem decide when to synchronize, or synchronize to the disk after the cache is full.
N: After every n transaction commits, MySQL will perform a disk synchronization command such as fsync to force the data in binlog_cache to be written to disk. If sync_binlog=1 , it means that the binary log is written by synchronously writing to the disk, and the write operation does not use the buffer of the operating system to write the binary log.
innodb_support_xa=1 can solve the situation that when sync_binlog=1 , the binary log has been written to the disk, but the transaction has not been committed, and the downtime occurs at this time, the transaction is rolled back when restarting, but the binary log is not rolled back.
6. Table structure definition file: MySQL has a file with frm as the suffix name, which records the table structure definition of the table.
7. Tablespace file: InnoDB adopts the design of storing the stored data according to the tablespace (tablespace). In the default configuration there will be a file named ibdata1 with an initial size of 10MB.
innodb_data_file_path: Specifies the path and size of the tablespace file.
innodb_file_per_table: If the parameter innodb_file_per_table is set, the user can create an independent table space for each table based on the InnoDB storage engine. The naming rules for independent tablespaces are: tablename.ibd. It should be noted that these separate tablespace files only store the table data , indexes, and insert cache BITMAP and other information , and the rest of the information is still stored in the default tablespace. MyISAM : .myd is my data, table data file .myi is my index, index file 8. Redo log files: Redo log files are used to achieve transaction durability.
Each InnoDB storage engine has at least one redo log file group (group), and each file group has at least two redo log files, such as the default ib_logfile0 and ib_logfile1. Users can set up multiple mirrored log groups and put different filegroups on different disks to improve the high availability of redo logs. Each redo log file in the log group is the same size and operates in a round-robin manner. The InnoDB storage engine first writes redo log file 1. When the end of the file is reached, it will switch to redo log file 2. When redo log file 2 is also full, it will switch to redo log file 1. .
innodb_log_file_size: Specifies the size of each redo log file.
innodb_log_files_in_group: Specifies the number of redo log files in the redo log group.
innodb_log_mirrored_log_groups: specifies the number of log mirror file groups, the default is 1, which means there is only one file group and no mirroring.
innodb_log_group_home_dir: specifies the path where the log file group is located.
innodb_flush_log_at_trx_commit : Policy used to control redo log flushing to disk.
0: Indicates that the redo log operation is not performed when the transaction is committed. This operation is only completed in the master thread, and the master thread will perform an fsync operation on the redo log file every 1 second.
1: Indicates that an fsync operation must be called when the transaction is committed.
2: Indicates that the redo log is written to the redo log file when the transaction is committed, but only to the cache of the file system, and no fsync operation is performed. Under this setting, when the MySQL database is down and the operating system is not down, the transaction will not be lost. When the operating system is down, the part of the transaction that is not flushed from the file system cache to the redo log file will be lost after restarting the database.
Second, binary log and redo log comparison
- The redo log is generated at the InnoDB storage engine layer , and the binary log is generated at the upper layer of the MySQL database .
- The redo log only records the transaction log for the InnoDB storage engine itself, while the binary log records all log records related to the MySQL database, including logs of other storage engines such as InnoDB, MyISAM, and Heap.
- The content and form of the two log records are different . The binary log is a logical log, which records the corresponding SQL statement , and the redo log is a physical format log, which records the modification of each page .
- The point in time of writing to disk is different . The binary log is written only once after the transaction is committed , while the redo log is written continuously while the transaction is in progress .