About MySQL database optimization from the O & M perspective

About MySQL database optimization from the O & M perspective

A mature database architecture is not designed with high availability, high scaling, and other features at the beginning. It is gradually improved with the increase in the number of users. This blog post focuses on the problems and optimization solutions faced by the MySQL database development cycle. Aside from the front-end applications, it is roughly divided into the following five stages:

1. Database Table Design

After the project is established, the Development Department develops the project according to the requirements of the product department. One part of the work of the development engineers is to design the table structure. This is very important for databases. Improper design will directly affect access speed and user experience. There are many influencing factors, such as slow queries, inefficient query statements, improper indexing, and database congestion (deadlock. Of course, a team of test engineers will perform stress tests and find bugs. For teams without test engineers, most development engineers do not consider whether the database design is reasonable at the initial stage, but complete function implementation and delivery as soon as possible. After a certain amount of Access to the project, the hidden problems will be exposed, and it is not so easy to modify them.

2. Database deployment

As the O & M engineer appeared, the initial access volume of the project was not very large, so a single deployment was sufficient to cope with QPS (query rate per second) at around 1500 ). Considering the high availability, you can use MySQL master-slave replication + Keepalived for double-click hot backup. Common cluster software include Keepalived and Heartbeat.

• Dual-machine Hot Standby blog: http://lizhenliang.blog.51cto.com/7876557/1362313

 

3. database performance optimization

If you deploy MySQL on a common X86 server, the MySQL theoretical value can handle about 2000 QPS without any optimization. After optimization, it may increase to around 2500 QPS. Otherwise, when the access volume reaches about 1500 concurrent connections, the database processing performance will slow down and the hardware resources will be rich, in this case, we should consider software issues. So how can we maximize the performance of the database? On the one hand, you can run multiple MySQL instances at a time to maximize the server performance. On the other hand, you can optimize the database. The default operating system and database configuration are usually conservative, the database may be limited to some extent. You can adjust these configurations to process as many connections as possible.

The specific optimization has the following three levels:

 

3.1 Database Configuration Optimization

MySQL commonly uses two storage engines: MyISAM, which does not support transaction processing, fast read performance, and table-level locks. The other is InnoDB, which supports ACID and is designed to maximize performance and lock rows for processing large data volumes.

• Table lock: it has low overhead, large lock granularity, high deadlock probability, and low concurrency.
• Row lock: large overhead, small lock granularity, low deadlock probability, and high concurrency.

Why are table locks and row locks? The main purpose is to ensure data integrity. For example, if a user is operating on a table and other users want to operate on this table, they must wait for the first user to complete the operation before other users can perform the operation, table locks and row locks serve this purpose. Otherwise, when multiple users operate on a table at the same time, data may conflict or be abnormal.

Based on the above, using the InnoDB Storage engine is the best choice, and is also the default storage engine in MySQL 5.5. Each storage engine has many associated parameters. The following lists the parameters that affect the database performance.

Default Value of public parameters:

1. max_connections =151
2. # Process the maximum number of connections simultaneously. We recommend that you set the maximum number of connections to around 80% of the maximum number of connections.
3. sort_buffer_size =2M
4. # The buffer size for sorting. It only applies to order by and group by. The value can be increased to 16 Mb.
5. query_cache_limit =1M
6. # Query cache restrictions: only query results below 1 MB will be cached, so as not to overwrite a large cache pool of result data
7. query_cache_size =16M
8. # View the buffer size, used to cache the SELECT query results. The next SELECT query will return results directly from the cache pool. This value can be multiplied as appropriate.
9. open_files_limit =1024
10. # Limit on the number of opened files. If the value displayed by show global status like 'open _ files 'is equal to or greater than the value of open_files_limit, the program cannot connect to the database or get stuck.

Default Value of MyISAM parameter:

1. key_buffer_size =16M
2. # Index cache size. Generally, it is set to 30-40% of the physical memory.
3. read_buffer_size =128K
4. # Read operation buffer size. It is recommended to set 16 M or 32 M

Default InnoDB parameters:

1. innodb_buffer_pool_size =128M
2. # Index and data buffer size, generally set the physical memory to 60%-70%
3. innodb_buffer_pool_instances =1
4. # Number of buffer pool instances. We recommend that you set four or eight instances.
5. innodb_flush_log_at_trx_commit =1
6. # Key parameter. 0 indicates that logs are written to and synchronized to the disk every second. If the database fails, transaction data is lost for about 1 second. 1. After each SQL statement is executed, it is written to the log and synchronized to the disk. the I/O overhead is high. After the SQL statement is executed, it is not efficient to wait for the log to read and write. 2 indicates that only logs are written to the system cache and synchronized to the disk every second, which is highly efficient. If the server fails, transaction data will be lost. We recommend setting 2, which does not require high data security. It has high performance and obvious effect after modification.
7. innodb_file_per_table = OFF
8. # The default value is shared tablespace. The size of the idbdata file in the shared tablespace is increasing, which affects the I/O performance. We recommend that you enable the standalone tablespace mode. The indexes and data of each table are stored in its own standalone tablespace, so that a single table can be moved across different databases.
9. innodb_log_buffer_size =8M
10. # Log buffer size. Because the log can be refreshed once every second at most, it generally does not need to exceed 16 Mb.

 

3.2 system kernel Optimization

Most MySQL instances are deployed on linux, so some operating system parameters also affect MySQL performance. The linux kernel is optimized as follows.

1. net.ipv4.tcp_fin_timeout =30
2. # TIME_WAIT timeout. The default value is 60 s.
3. net.ipv4.tcp_tw_reuse =1
4. #1 indicates Enable reuse, TIME_WAIT socket is allowed to be re-used for new TCP connections, and 0 indicates disable
5. net.ipv4.tcp_tw_recycle =1
6. #1 indicates enabling TIME_WAIT socket fast recovery, and 0 indicates disabling
7. net.ipv4.tcp_max_tw_buckets =4096
8. # The system maintains the maximum number of TIME_WAIT sockets. If this number is exceeded, the system will randomly clear some TIME_WAIT and print the warning information.
9. net.ipv4.tcp_max_syn_backlog =4096
10. # Enter the maximum length of the SYN queue and increase the queue length to accommodate more waiting connections

In linux, if the number of file handles opened by a process exceeds the system's default value of 1024, the "too program files open" message is displayed. Therefore, you need to adjust the file handle limit.

1. # Vi/etc/security/limits. conf # Add the following configuration. * indicates all users. You can also specify users to restart the system.
2. * soft nofile 65535
3. * hard nofile 65535
4. # Ulimit-SHn 65535 # effective immediately

 

3.3 hardware configuration

Increase physical memory and improve file system performance. The Linux kernel allocates a cache area (system cache and data cache) from the memory to store hot data. Through the file system delay writing mechanism, when the conditions are met (for example, the cache size reaches a certain percentage or the sync command is executed), it is synchronized to the disk. That is to say, the larger the physical memory, the larger the allocated cache area, the more cached data. Of course, some cached data will be lost due to server faults.

The SSD hard disk replaces the SAS hard disk. The RAID level is adjusted to RAID 1 + 0, which has better read/write performance (IOPS) than RAID 1 and RAID 5. After all, the database pressure mainly comes from disk I/O.

 

4. database architecture Scaling

As the business volume grows, the performance of a single database server is no longer able to meet business needs. You should add machines to the cluster ~~~. The main idea is to break down the load of a single database, break through the disk I/O performance, store hot data in the cache, and reduce the disk I/O Access frequency.

 

4.1 master-slave replication and read/write splitting

Because most databases in the production environment are read operations, a master-slave multi-slave architecture is deployed. The master database is responsible for write operations and double-click hot backup. Multiple slave databases are used for load balancing, read operations. Mainstream load balancers include LVS, HAProxy, and Nginx. How can I implement read/write splitting? Most enterprises implement read/write separation at the code level, with high efficiency. Another method is to implement read/write splitting through a Proxy program, with fewer applications in the enterprise. Common proxies include MySQL Proxy and Amoeba. In this database cluster architecture, the high concurrency of databases is greatly increased to solve the performance bottleneck of a single database. If one slave database can process 2000 QPS, five slave databases can process QPS, and the horizontal scalability of the database is also very easy.

Sometimes, in the face of a large number of write operations, a single write can not meet the business needs. If dual-master is used, database data inconsistency may occur. This is because different users in the application may operate on the two databases, simultaneous update operations cause conflicts or inconsistencies between the two database databases. In a single database, MySQL uses the storage engine mechanism Table lock and row lock to ensure data integrity. How can this problem be solved in multiple master databases? A Master-slave replication management tool developed based on the perl language, called MySQL-MMM (Master-Master replication managerfor Mysql, Mysql Master replication manager ), the biggest advantage of this tool is that it only provides write operations for one database at a time, effectively ensuring data consistency.

• Master-slave replication blog:
• Read/write splitting blog:
• MySQL-MMM blog:

 

4.2 Add Cache

Add a cache system for the database and cache hot data to the memory. If the memory cache contains the data to be requested, the database will no longer return results, improving read performance. The cache implementation includes local cache and distributed cache. The local cache caches data to the local server memory or files, which is fast. Distributed caching can cache massive amounts of data, which is easy to expand. The mainstream distributed caching systems include memcached and redis. memcached has stable performance and data is cached in the memory. The speed is very fast and the QPS can reach about. If you want data persistence, use redis with a performance not lower than memcached.

Working Process:

 

4.3 sub-Databases

Database sharding refers to splitting related tables into different databases based on different services, such as databases such as web, bbs, and blog. If the business volume is large, you can also take the split database as the master from the architecture, further avoiding the pressure on a single database.

 

4.4 sub-tables

With the increase in data volume, a table in the database contains millions of data records, resulting in a long query and insertion time. How can we solve the pressure on a single table? You should consider whether to split the table into multiple small tables to reduce the pressure on a single table and improve the processing efficiency. This method is called table sharding.

Table sharding technology is troublesome. to modify the SQL statements in the program code, you must manually create other tables. You can also use the merge storage engine to implement table sharding, which is much simpler. After Table sharding, the program operates on a summary table. This table does not store data, but only has some table sharding relationships and data update methods. The summary table will be queried Based on Different queries, assigning pressure to different small tables improves the concurrency and disk I/O performance.

Table sharding is divided into vertical sharding and horizontal sharding:

• Vertical Split: Splits a table with many fields into multiple tables to solve the table width problem. You can place infrequently used fields in a single table, separate large fields in a table, or put closely related fields in a table.
• Horizontal Split: Split the original table into multiple tables. Each table has the same structure, solving the problem of large data volume in a single table.

 

4.5 partitions

Partitioning refers to dividing the data in a table into multiple blocks. These blocks can be stored on one disk or on different disks. After partitioning, a table is displayed on the surface, however, data is hashed in multiple locations. As a result, multiple hard disks process different requests at the same time to improve disk I/O read/write performance.

Note: Adding cache, database sharding, table sharding, and partition are mainly implemented by programmers.

 

5. Database Maintenance

Database maintenance is the main task of O & M engineers or DBAs, including performance monitoring, performance analysis, performance tuning, database backup and recovery.

 

5.1 key performance indicators

• QPS, Queries Per Second: Queries Per Second, the number of Queries that a database can process Per Second
• TPS, Transactions Per Second: number of Transactions processed Per Second

You can view the running status through show status. There are more than 300 status information records. Several Values help us calculate the QPS and TPS, as shown below:

• Uptime: the actual number of seconds that the server is running.
• Questions: number of queries sent to the database
• Com_select: number of queries, which are used to operate the database
• Com_insert: Number of inserts
• Com_delete: Number of Deletions
• Com_update: number of updates
• Com_commit: number of transactions
• Com_rollback: Number of rollbacks

Then, the calculation method is used to calculate the QPS based on Questions:

1. mysql> show global status like 'Questions';
2. mysql> show global status like 'Uptime';

QPS = Questions/Uptime

Calculate TPS Based on Com_commit and Com_rollback:

1. mysql> show global status like 'Com_commit';
2. mysql> show global status like 'Com_rollback';
3. mysql> show global status like 'Uptime';

Another calculation method: Calculate QPS Based on Com_select, Com_insert, Com_delete, and Com_update:

1. mysql> show global status whereVariable_namein('com_select','com_insert','com_delete','com_update');

Wait 1 second and then run again to get the Interval Difference. The second time each variable value minus the first corresponding variable value is QPS.

TPS calculation method:

1. mysql> show global status whereVariable_namein('com_select','com_insert','com_delete','com_update');

Calculating TPS is not a query operation. Just calculate the four values of insert, delete, and update.

According to tests on the two calculation methods, Questions is more accurate when there are many myisam tables in the database. When there are many innodb tables in the database, the computation with Com _ * is more accurate.

 

5.2 enable slow query log

MySQL enables slow query logs and analyzes which SQL statement is slow. You can use set to set the variable and restart the service to make it invalid. You can add the parameter in my. cnf to take effect permanently.

1. Mysql> setglobal slow-query-log = on # enable the slow query function
2. Mysql> setglobal slow_query_log_file = '/var/log/mysql/mysql-slow.log'; # specify the location of the slow query log file
3. Mysql> setglobal log_queries_not_using_indexes = on; # records queries without Indexes
4. Mysql> setglobal long_query_time = 1; # Only records slow queries with processing time greater than 1 s.

To analyze slow query logs, you can use the mysqldumpslow tool provided by MySQL to analyze the logs.

1. # Mysqldumpslow-t 3/var/log/mysql/mysql-slow.log # view the slowest first three queries

Percona's pt-query-digest tool can also be used to analyze slow log, binlog, and general log with comprehensive log analysis functions.

Analyze slow query logs:

1. pt-query-digest /var/log/mysql/mysql-slow.log

Analyze binlog logs:

1. mysqlbinlog mysql-bin.000001>mysql-bin.000001.sql
2. pt-query-digest –type=binlog mysql-bin.000001.sql

Analyze common logs:

1. pt-query-digest –type=genlog localhost.log

 

5.3 Database Backup

Backing up a database is the most basic task and the most important task. Otherwise, the consequences will be very serious. You know! However, because the database is large and hundreds of GB of data is often time-consuming, you should select an efficient backup policy. For databases with large data volumes, Incremental backup is generally used. Common backup tools include mysqldump, mysqlhotcopy, and xtrabackup. mysqldump is suitable for small databases. Because it is a logical backup, it takes a long time to back up and restore data. Mysqlhotcopy and xtrabackup are physical backups. backup and recovery are fast and hot copies are performed without affecting database services. We recommend that you use xtrabackup to support Incremental backup.

• Xtrabackup backup tools use blog: http://lizhenliang.blog.51cto.com/7876557/1612800

 

5.4 database repair

Sometimes the MySQL server suddenly loses power and shuts down abnormally, causing table damage and the table data cannot be read. In this case, you can use the MySQL tool, myisamchk and mysqlcheck.

Myisamchk: Only myisam tables can be repaired. You need to stop the database.

Common parameters:

• -F-force repair: overwrite the old temporary files. It is generally not used.
• -R-recover recovery mode
• -Q-quik quick recovery
• -A-analyze analysis table
• -O-safe-recover: Old recovery mode. If-r cannot be repaired, use this parameter to try.
• -F-fast: Only checks tables that are not normally closed.

Quick repair of the weibo database:

1. # cd /var/lib/mysql/weibo
2. # myisamchk -r -q *.MYI

Mysqlcheck: Both myisam and innodb tables can be used without stopping the database. For example, to fix a single table, you can add a table name after the database, separated by spaces.

Common parameters:

• -A-all-databases: Check all databases
• -R-repair
• -C-check checklist, default option
• -A-analyze analysis table
• -O-optimize optimization table
• -Q-quik: fastest table check or repair
• -F-fast: Only checks tables that are not normally closed.

Quick repair of the weibo database:

1. mysqlcheck -r -q -uroot -p123 weibo

 

5.5 In addition, view CPU and I/O performance methods

View CPU Performance

Parameter-P indicates the number of CPUs displayed. ALL indicates the number of CPUs, and only the number of CPUs can be displayed.

View I/O performance

The-m parameter is displayed in MB. The default value is K.

• % Util: when it reaches 100%, it indicates that I/O is very busy.
• Await: the waiting time of a request in the queue directly affects the read time.
• I/O limit: IOPS (r/s + w/s), usually around 1200. (IOPS, read/write (I/O) operations per second)
• I/O bandwidth: in sequential read/write mode, the theoretical value of the SAS hard disk is about 300 MB/S, and that of the SSD hard disk is about 600 Mb/s.

The above are some of the major optimization solutions I have summarized over the past three years using MySQL, which have limited capabilities and are not comprehensive. However, these solutions can basically meet the database requirements of small and medium enterprises. Due to the limitations of the original design of relational databases, some BAT companies put massive amounts of data into relational databases, which has not achieved better performance in massive data query and analysis. As a result, NoSQL is very popular. Non-relational databases, large data volumes, and high performance make up for some shortcomings of relational databases. Most companies have gradually put some business data into NoSQL, such as MongoDB and HBase. Distributed File systems are used for data storage, such as HDFS and GFS. Massive Data computing and analysis uses Hadoop, Spark, and Storm. These are cutting-edge technologies related to O & M, and are also the main learning objects in terms of storage. Let's work together! Which of the following bloggers has a better optimization solution? please contact us.

This article permanently updates the link address: