Feed aggregator

Sometimes, it is required to enable the general query log (which is disabled by default). If the general query log is enabled the server writes to this log information when clients connect or disconnect, and each SQL statement received from the client.

The question is, does enabling the general query log affects the MySQL performance ?
Also, it is possible to record the output of this log into either file or table in the mysql database (mysql.general_log), what is the performance impact of each one?

Let's do some simple benchmark for those scenarios to measure the actual impact on the mysql performance.

System Information: HW configurations:

• CPU: Intel® Core™ i7-3520M Processor (4M Cache, up to 3.60 GHz).
• 2 cores, 4 threads, HT enabled.
• Memory: 8GB RAM (1600).
• Storage: HDD 1TB/ 5400RPM.

Software configurations:

• OS: Ubuntu 12.04
• MySQL Server: 5.6.17
• Sysbench: 0.4.12

Test Information:

• Sysbench command: sysbench --num-threads=1 --max-requests=1000 --db-driver=mysql --test=oltp --mysql-table-engine=InnoDB --mysql-user=root run .
• Table structure which was used by sysbench tests: mysql> show create table sbtest.sbtest\G CREATE TABLE `sbtest` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `k` int(10) unsigned NOT NULL DEFAULT '0', `c` char(120) NOT NULL DEFAULT '', `pad` char(60) NOT NULL DEFAULT '', PRIMARY KEY (`id`), KEY `k` (`k`) ) ENGINE=InnoDB AUTO_INCREMENT=8574 DEFAULT CHARSET=latin1

Note:

The test had been made against 1,2,4,8,16 and 32 threads, each throughput/response time value for each thread's number for each test case is generated by the average of ten (10) times execution.

General log Disabled:

To make sure that the general query log is disabled:

mysql> show global variables like'general_log'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | general_log | OFF | +---------------+-------+

Testing results:

General log Enabled:

The general query log is a dynamic variable which means that it could be enabled or disabled ONLINE without restarting MySQL (since MySQL 5.1):

mysql> SET GLOBAL general_log=ON;

We can choose the output for this log to be either in a log file (by default) or in a MySQL table (mysql.general_log).

What are the benefits that we might get if we have the log output to be stored in a table not in a file?

• We can use the normal SQL statements to access the log contents to get information about specific criteria (e.g. using WHERE condition) and this is a little harder when dealing with files.
• The log contents could be accessed remotely if someone can connect to the MySQL server.
• Standard format for the log entries.
• If the CSV engine is used for the log table, it will be easy to import the CSV file into spreadsheets.
• It is easy to expire the logs by simply TRUNCATE the log table.
• Log rotation is possible by using RENAME TABLE statement.
• Log entries are not replicated to the slave because they are not written to the binary logs.
• The mysqldump does not include the log tables contents (general_log or slow_log) in the backup even if --all-databases backup option is used.

So, let's check the performance impact then of each log output.

Output is FILE:

To check the output destination of the general log, the following command should be used:

mysql> show global variables like'log_output'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_output | FILE | +---------------+-------+

Testing results:

Output is TABLE (CSV table):

To change the output destination of the general log from file to table (CSV by default), the following command should be used:

mysql> SET GLOBAL log_output='TABLE'; mysql> show global variables like'log_output'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_output | TABLE | +---------------+-------+

Testing results:

Output is TABLE (MyISAM table):

Maybe due to the nature of the CSV storage ENGINE we faced performance issues in the previous case. Is it possible to change the table engine of the general_log table?

The answer is yes, but unfortunately, we are restricted to use only MyISAM storage engine and no engines other than CSV or MyISAM are allowed. Check this link for more information.

To alter the log table, you must first disable the logging:

mysql> alter table mysql.general_log engine=MYISAM; ERROR 1580 (HY000): You cannot 'ALTER' a log table if logging is enabled mysql> SET GLOBAL general_log=OFF; mysql> alter table mysql.general_log engine=MYISAM; mysql> SET GLOBAL general_log=ON;

Testing results:

Output is TABLE (MyISAM table with some structures changes):

In general, to make any SQL query work faster, we might need to optimize the table structure, add indexes, re-write the query, .. etc.

The following is the general log table structure:

mysql> show create table mysql.general_log\G CREATE TABLE `general_log` ( `event_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `user_host` mediumtext NOT NULL, `thread_id` bigint(21) unsigned NOT NULL, `server_id` int(10) unsigned NOT NULL, `command_type` varchar(64) NOT NULL, `argument` mediumtext NOT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='General log'

Let's check what can we do to optimize the general_log table structure (other suggestions are welcomed):

• Can we create partitions on that table which might boost our search?
  Although this is a normal MyISAM table but partitioning IS NOT allowed for the log tables (by the way, partitioning is not permitted also for CSV tables).
• Can we change the datatype of the `user_host` column from mediumtext to e.g. varchar(100)? (The max length of this column's data on my machine didn't exceed 50 characters)
  While it is - syntax wise - accepted but no logs will be stored in the table after that and the following error will be printed in the error log file: 2014-03-06 18:44:21 6987 [ERROR] Failed to write to mysql.general_log: 2014-03-06 18:44:23 6987 [ERROR] Incorrect definition of table mysql.general_log: expected column 'user_host' at position 1 to have type mediumtext, found type varchar(100).
  
• What about creating indexes on the columns we will use for most of our searches (`event_time` and `argument`)? lets try that!
  
  • Add index on `event_time` column:
    mysql> SET GLOBAL general_log=OFF; mysql> alter table mysql.general_log add index ev_tm_idx(`event_time`); mysql> show create table mysql.general_log\G CREATE TABLE `general_log` ( `event_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `user_host` mediumtext NOT NULL, `thread_id` bigint(21) unsigned NOT NULL, `server_id` int(10) unsigned NOT NULL, `command_type` varchar(64) NOT NULL, `argument` mediumtext NOT NULL, KEY `ev_tm_idx` (`event_time`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='General log' mysql> SET GLOBAL general_log=ON;
    

    Testing results:

• Add FULLTEXT index on `argument` column:
  mysql> SET GLOBAL general_log=OFF; mysql> alter table mysql.general_log add fulltext index (`argument`); mysql> show create table mysql.general_log\G CREATE TABLE `general_log` ( `event_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `user_host` mediumtext NOT NULL, `thread_id` bigint(21) unsigned NOT NULL, `server_id` int(10) unsigned NOT NULL, `command_type` varchar(64) NOT NULL, `argument` mediumtext NOT NULL, KEY `ev_tm_idx` (`event_time`), FULLTEXT KEY `argument` (`argument`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='General log' mysql> SET GLOBAL general_log=ON;
  

  Testing results:

To make it more clear, the following is the combination of all results in one graph followed by response time comparison:

The raw results in Transactions / Sec might be useful:

Threads12481632General log disabled383.996814.7591421.2881674.7331414.9851071.189General log enabled (File)281.642521.391230.7431406.1271095.896923.986General log enabled (CSV Table)231.659447.173787.578507.846426.324439.992General log enabled (MyISAM Table)249.47536.379933.304532.912476.454454.015General log enabled (MyISAM Table + index)238.508430.05875.209465.464465.464395.063General log enabled (MyISAM Table + Fulltext index)157.436236.156210.968212.273218.617220.701
Conclusion:

• The best MySQL performance - among all above test cases - could be achieved by disabling the general query log, e.g. if we compared the above results for the case 4 concurrent threads (the highest value for most scenarios) we would find that:
  • Using the general log enabled (general_log = ON) and the log destination is file (log_output = FILE) decreased the throughput by 13.4% and increased the response time by 17.5%.
  • Using the general log enabled and the log destination is CSV table decreased the throughput by 44.6% and increased the response time by 90%.
  • Using the general log enabled and the log destination is MyISAM table decreased the throughput by 34.3% and increased the response time by 59%.
  • Using the general log enabled and the log destination is MyISAM having an index added on column `event_time` decreased the throughput by 38.4% and increased the response time by 73%.
  • Using the general log enabled and the log destination is MyISAM having an index added on column `event_time` and FULLTEXT index added on column `argument` decreased the throughput by 85% and increased the response time by 542%.
• Although using table as a log output destination has many benefits - as described above - but it has more negative impact on the MySQL performance as compared to log file.
• Increasing the number of concurrently running threads - in the case of log_output=TABLE - will increase the general_log table contention which is controlled by the table locking level for MyISAM or CSV ENGINES.
• Like any other MySQL table - as many rows inserted in the log table as more negative performance impact.
• Although mysqldump does not include the log tables contents in the backup but this is not the case when having full physical backup using Xtrabackup or any other physical backup based tools.
• Finally, it is preferred to only enable the general query log when it is really needed and it is not recommended to enable it in a production system. It could be enabled (dynamically) for a while then should be disabled again once we have got what we are searching for.

Taxonomy upgrade extras: general query logperformance

Sometimes, it is required to enable the general query log (which is disabled by default). If the general query log is enabled the server writes to this log information when clients connect or disconnect, and each SQL statement received from the client.

The question is, does enabling the general query log affects the MySQL performance ?
Also, it is possible to record the output of this log into either file or table in the mysql database (mysql.general_log), what is the performance impact of each one?

Let's do some simple benchmark for those scenarios to measure the actual impact on the mysql performance.

System Information: HW configurations:

• CPU: Intel® Core™ i7-3520M Processor (4M Cache, up to 3.60 GHz).
• 2 cores, 4 threads, HT enabled.
• Memory: 8GB RAM (1600).
• Storage: HDD 1TB/ 5400RPM.

Software configurations:

• OS: Ubuntu 12.04
• MySQL Server: 5.6.17
• Sysbench: 0.4.12

Test Information:

• Sysbench command: sysbench --num-threads=1 --max-requests=1000 --db-driver=mysql --test=oltp --mysql-table-engine=InnoDB --mysql-user=root run .
• Table structure which was used by sysbench tests: mysql> show create table sbtest.sbtest\G CREATE TABLE `sbtest` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `k` int(10) unsigned NOT NULL DEFAULT '0', `c` char(120) NOT NULL DEFAULT '', `pad` char(60) NOT NULL DEFAULT '', PRIMARY KEY (`id`), KEY `k` (`k`) ) ENGINE=InnoDB AUTO_INCREMENT=8574 DEFAULT CHARSET=latin1

Note:

The test had been made against 1,2,4,8,16 and 32 threads, each throughput/response time value for each thread's number for each test case is generated by the average of ten (10) times execution.

General log Disabled:

To make sure that the general query log is disabled:

mysql> show global variables like'general_log'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | general_log | OFF | +---------------+-------+

Testing results:

General log Enabled:

The general query log is a dynamic variable which means that it could be enabled or disabled ONLINE without restarting MySQL (since MySQL 5.1):

mysql> SET GLOBAL general_log=ON;

We can choose the output for this log to be either in a log file (by default) or in a MySQL table (mysql.general_log).

What are the benefits that we might get if we have the log output to be stored in a table not in a file?

• We can use the normal SQL statements to access the log contents to get information about specific criteria (e.g. using WHERE condition) and this is a little harder when dealing with files.
• The log contents could be accessed remotely if someone can connect to the MySQL server.
• Standard format for the log entries.
• If the CSV engine is used for the log table, it will be easy to import the CSV file into spreadsheets.
• It is easy to expire the logs by simply TRUNCATE the log table.
• Log rotation is possible by using RENAME TABLE statement.
• Log entries are not replicated to the slave because they are not written to the binary logs.
• The mysqldump does not include the log tables contents (general_log or slow_log) in the backup even if --all-databases backup option is used.

So, let's check the performance impact then of each log output.

Output is FILE:

To check the output destination of the general log, the following command should be used:

mysql> show global variables like'log_output'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_output | FILE | +---------------+-------+

Testing results:

Output is TABLE (CSV table):

To change the output destination of the general log from file to table (CSV by default), the following command should be used:

mysql> SET GLOBAL log_output='TABLE'; mysql> show global variables like'log_output'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_output | TABLE | +---------------+-------+

Testing results:

Output is TABLE (MyISAM table):

Maybe due to the nature of the CSV storage ENGINE we faced performance issues in the previous case. Is it possible to change the table engine of the general_log table?

The answer is yes, but unfortunately, we are restricted to use only MyISAM storage engine and no engines other than CSV or MyISAM are allowed. Check this link for more information.

To alter the log table, you must first disable the logging:

mysql> alter table mysql.general_log engine=MYISAM; ERROR 1580 (HY000): You cannot 'ALTER' a log table if logging is enabled mysql> SET GLOBAL general_log=OFF; mysql> alter table mysql.general_log engine=MYISAM; mysql> SET GLOBAL general_log=ON;

Testing results:

Output is TABLE (MyISAM table with some structures changes):

In general, to make any SQL query work faster, we might need to optimize the table structure, add indexes, re-write the query, .. etc.

The following is the general log table structure:

mysql> show create table mysql.general_log\G CREATE TABLE `general_log` ( `event_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `user_host` mediumtext NOT NULL, `thread_id` bigint(21) unsigned NOT NULL, `server_id` int(10) unsigned NOT NULL, `command_type` varchar(64) NOT NULL, `argument` mediumtext NOT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='General log'

Let's check what can we do to optimize the general_log table structure (other suggestions are welcomed):

• Can we create partitions on that table which might boost our search?
  Although this is a normal MyISAM table but partitioning IS NOT allowed for the log tables (by the way, partitioning is not permitted also for CSV tables).
• Can we change the datatype of the `user_host` column from mediumtext to e.g. varchar(100)? (The max length of this column's data on my machine didn't exceed 50 characters)
  While it is - syntax wise - accepted but no logs will be stored in the table after that and the following error will be printed in the error log file: 2014-03-06 18:44:21 6987 [ERROR] Failed to write to mysql.general_log: 2014-03-06 18:44:23 6987 [ERROR] Incorrect definition of table mysql.general_log: expected column 'user_host' at position 1 to have type mediumtext, found type varchar(100).
  
• What about creating indexes on the columns we will use for most of our searches (`event_time` and `argument`)? lets try that!
  
  • Add index on `event_time` column:
    mysql> SET GLOBAL general_log=OFF; mysql> alter table mysql.general_log add index ev_tm_idx(`event_time`); mysql> show create table mysql.general_log\G CREATE TABLE `general_log` ( `event_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `user_host` mediumtext NOT NULL, `thread_id` bigint(21) unsigned NOT NULL, `server_id` int(10) unsigned NOT NULL, `command_type` varchar(64) NOT NULL, `argument` mediumtext NOT NULL, KEY `ev_tm_idx` (`event_time`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='General log' mysql> SET GLOBAL general_log=ON;
    

    Testing results:

• Add FULLTEXT index on `argument` column:
  mysql> SET GLOBAL general_log=OFF; mysql> alter table mysql.general_log add fulltext index (`argument`); mysql> show create table mysql.general_log\G CREATE TABLE `general_log` ( `event_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `user_host` mediumtext NOT NULL, `thread_id` bigint(21) unsigned NOT NULL, `server_id` int(10) unsigned NOT NULL, `command_type` varchar(64) NOT NULL, `argument` mediumtext NOT NULL, KEY `ev_tm_idx` (`event_time`), FULLTEXT KEY `argument` (`argument`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='General log' mysql> SET GLOBAL general_log=ON;
  

  Testing results:

To make it more clear, the following is the combination of all results in one graph followed by response time comparison:

The raw results in Transactions / Sec might be useful:

Threads12481632General log disabled383.996814.7591421.2881674.7331414.9851071.189General log enabled (File)281.642521.391230.7431406.1271095.896923.986General log enabled (CSV Table)231.659447.173787.578507.846426.324439.992General log enabled (MyISAM Table)249.47536.379933.304532.912476.454454.015General log enabled (MyISAM Table + index)238.508430.05875.209465.464465.464395.063General log enabled (MyISAM Table + Fulltext index)157.436236.156210.968212.273218.617220.701
Conclusion:

• The best MySQL performance - among all above test cases - could be achieved by disabling the general query log, e.g. if we compared the above results for the case 4 concurrent threads (the highest value for most scenarios) we would find that:
  • Using the general log enabled (general_log = ON) and the log destination is file (log_output = FILE) decreased the throughput by 13.4% and increased the response time by 17.5%.
  • Using the general log enabled and the log destination is CSV table decreased the throughput by 44.6% and increased the response time by 90%.
  • Using the general log enabled and the log destination is MyISAM table decreased the throughput by 34.3% and increased the response time by 59%.
  • Using the general log enabled and the log destination is MyISAM having an index added on column `event_time` decreased the throughput by 38.4% and increased the response time by 73%.
  • Using the general log enabled and the log destination is MyISAM having an index added on column `event_time` and FULLTEXT index added on column `argument` decreased the throughput by 85% and increased the response time by 542%.
• Although using table as a log output destination has many benefits - as described above - but it has more negative impact on the MySQL performance as compared to log file.
• Increasing the number of concurrently running threads - in the case of log_output=TABLE - will increase the general_log table contention which is controlled by the table locking level for MyISAM or CSV ENGINES.
• Like any other MySQL table - as many rows inserted in the log table as more negative performance impact.
• Although mysqldump does not include the log tables contents in the backup but this is not the case when having full physical backup using Xtrabackup or any other physical backup based tools.
• Finally, it is preferred to only enable the general query log when it is really needed and it is not recommended to enable it in a production system. It could be enabled (dynamically) for a while then should be disabled again once we have got what we are searching for.

Sometimes, it is required to enable the general query log (which is disabled by default). If the general query log is enabled the server writes to this log information when clients connect or disconnect, and each SQL statement received from the client.

The question is, does enabling the general query log affects the MySQL performance ?
Also, it is possible to record the output of this log into either file or table in the mysql database (mysql.general_log), what is the performance impact of each one?

Let's do some simple benchmark for those scenarios to measure the actual impact on the mysql performance.

System Information: HW configurations:

• CPU: Intel® Core™ i7-3520M Processor (4M Cache, up to 3.60 GHz).
• 2 cores, 4 threads, HT enabled.
• Memory: 8GB RAM (1600).
• Storage: HDD 1TB/ 5400RPM.

Software configurations:

• OS: Ubuntu 12.04
• MySQL Server: 5.6.17
• Sysbench: 0.4.12

Test Information:

• Sysbench command: sysbench --num-threads=1 --max-requests=1000 --db-driver=mysql --test=oltp --mysql-table-engine=InnoDB --mysql-user=root run .
• Table structure which was used by sysbench tests: mysql> show create table sbtest.sbtest\G CREATE TABLE `sbtest` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `k` int(10) unsigned NOT NULL DEFAULT '0', `c` char(120) NOT NULL DEFAULT '', `pad` char(60) NOT NULL DEFAULT '', PRIMARY KEY (`id`), KEY `k` (`k`) ) ENGINE=InnoDB AUTO_INCREMENT=8574 DEFAULT CHARSET=latin1

Note:

The test had been made against 1,2,4,8,16 and 32 threads, each throughput/response time value for each thread's number for each test case is generated by the average of ten (10) times execution.

General log Disabled:

To make sure that the general query log is disabled:

mysql> show global variables like'general_log'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | general_log | OFF | +---------------+-------+

Testing results:

General log Enabled:

The general query log is a dynamic variable which means that it could be enabled or disabled ONLINE without restarting MySQL (since MySQL 5.1):

mysql> SET GLOBAL general_log=ON;

We can choose the output for this log to be either in a log file (by default) or in a MySQL table (mysql.general_log).

What are the benefits that we might get if we have the log output to be stored in a table not in a file?

• We can use the normal SQL statements to access the log contents to get information about specific criteria (e.g. using WHERE condition) and this is a little harder when dealing with files.
• The log contents could be accessed remotely if someone can connect to the MySQL server.
• Standard format for the log entries.
• If the CSV engine is used for the log table, it will be easy to import the CSV file into spreadsheets.
• It is easy to expire the logs by simply TRUNCATE the log table.
• Log rotation is possible by using RENAME TABLE statement.
• Log entries are not replicated to the slave because they are not written to the binary logs.
• The mysqldump does not include the log tables contents (general_log or slow_log) in the backup even if --all-databases backup option is used.

So, let's check the performance impact then of each log output.

Output is FILE:

To check the output destination of the general log, the following command should be used:

mysql> show global variables like'log_output'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_output | FILE | +---------------+-------+

Testing results:

Output is TABLE (CSV table):

To change the output destination of the general log from file to table (CSV by default), the following command should be used:

mysql> SET GLOBAL log_output='TABLE'; mysql> show global variables like'log_output'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_output | TABLE | +---------------+-------+

Testing results:

Output is TABLE (MyISAM table):

Maybe due to the nature of the CSV storage ENGINE we faced performance issues in the previous case. Is it possible to change the table engine of the general_log table?

The answer is yes, but unfortunately, we are restricted to use only MyISAM storage engine and no engines other than CSV or MyISAM are allowed. Check this link for more information.

To alter the log table, you must first disable the logging:

mysql> alter table mysql.general_log engine=MYISAM; ERROR 1580 (HY000): You cannot 'ALTER' a log table if logging is enabled mysql> SET GLOBAL general_log=OFF; mysql> alter table mysql.general_log engine=MYISAM; mysql> SET GLOBAL general_log=ON;

Testing results:

Output is TABLE (MyISAM table with some structures changes):

In general, to make any SQL query work faster, we might need to optimize the table structure, add indexes, re-write the query, .. etc.

The following is the general log table structure:

mysql> show create table mysql.general_log\G CREATE TABLE `general_log` ( `event_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `user_host` mediumtext NOT NULL, `thread_id` bigint(21) unsigned NOT NULL, `server_id` int(10) unsigned NOT NULL, `command_type` varchar(64) NOT NULL, `argument` mediumtext NOT NULL ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='General log'

Let's check what can we do to optimize the general_log table structure (other suggestions are welcomed):

• Can we create partitions on that table which might boost our search?
  Although this is a normal MyISAM table but partitioning IS NOT allowed for the log tables (by the way, partitioning is not permitted also for CSV tables).
• Can we change the datatype of the `user_host` column from mediumtext to e.g. varchar(100)? (The max length of this column's data on my machine didn't exceed 50 characters)
  While it is - syntax wise - accepted but no logs will be stored in the table after that and the following error will be printed in the error log file: 2014-03-06 18:44:21 6987 [ERROR] Failed to write to mysql.general_log: 2014-03-06 18:44:23 6987 [ERROR] Incorrect definition of table mysql.general_log: expected column 'user_host' at position 1 to have type mediumtext, found type varchar(100).
  
• What about creating indexes on the columns we will use for most of our searches (`event_time` and `argument`)? lets try that!
  
  • Add index on `event_time` column:
    mysql> SET GLOBAL general_log=OFF; mysql> alter table mysql.general_log add index ev_tm_idx(`event_time`); mysql> show create table mysql.general_log\G CREATE TABLE `general_log` ( `event_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `user_host` mediumtext NOT NULL, `thread_id` bigint(21) unsigned NOT NULL, `server_id` int(10) unsigned NOT NULL, `command_type` varchar(64) NOT NULL, `argument` mediumtext NOT NULL, KEY `ev_tm_idx` (`event_time`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='General log' mysql> SET GLOBAL general_log=ON;
    

    Testing results:

• Add FULLTEXT index on `argument` column:
  mysql> SET GLOBAL general_log=OFF; mysql> alter table mysql.general_log add fulltext index (`argument`); mysql> show create table mysql.general_log\G CREATE TABLE `general_log` ( `event_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `user_host` mediumtext NOT NULL, `thread_id` bigint(21) unsigned NOT NULL, `server_id` int(10) unsigned NOT NULL, `command_type` varchar(64) NOT NULL, `argument` mediumtext NOT NULL, KEY `ev_tm_idx` (`event_time`), FULLTEXT KEY `argument` (`argument`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COMMENT='General log' mysql> SET GLOBAL general_log=ON;
  

  Testing results:

To make it more clear, the following is the combination of all results in one graph followed by response time comparison:

The raw results in Transactions / Sec might be useful:

Threads12481632General log disabled383.996814.7591421.2881674.7331414.9851071.189General log enabled (File)281.642521.391230.7431406.1271095.896923.986General log enabled (CSV Table)231.659447.173787.578507.846426.324439.992General log enabled (MyISAM Table)249.47536.379933.304532.912476.454454.015General log enabled (MyISAM Table + index)238.508430.05875.209465.464465.464395.063General log enabled (MyISAM Table + Fulltext index)157.436236.156210.968212.273218.617220.701
Conclusion:

• The best MySQL performance - among all above test cases - could be achieved by disabling the general query log, e.g. if we compared the above results for the case 4 concurrent threads (the highest value for most scenarios) we would find that:
  • Using the general log enabled (general_log = ON) and the log destination is file (log_output = FILE) decreased the throughput by 13.4% and increased the response time by 17.5%.
  • Using the general log enabled and the log destination is CSV table decreased the throughput by 44.6% and increased the response time by 90%.
  • Using the general log enabled and the log destination is MyISAM table decreased the throughput by 34.3% and increased the response time by 59%.
  • Using the general log enabled and the log destination is MyISAM having an index added on column `event_time` decreased the throughput by 38.4% and increased the response time by 73%.
  • Using the general log enabled and the log destination is MyISAM having an index added on column `event_time` and FULLTEXT index added on column `argument` decreased the throughput by 85% and increased the response time by 542%.
• Although using table as a log output destination has many benefits - as described above - but it has more negative impact on the MySQL performance as compared to log file.
• Increasing the number of concurrently running threads - in the case of log_output=TABLE - will increase the general_log table contention which is controlled by the table locking level for MyISAM or CSV ENGINES.
• Like any other MySQL table - as many rows inserted in the log table as more negative performance impact.
• Although mysqldump does not include the log tables contents in the backup but this is not the case when having full physical backup using Xtrabackup or any other physical backup based tools.
• Finally, it is preferred to only enable the general query log when it is really needed and it is not recommended to enable it in a production system. It could be enabled (dynamically) for a while then should be disabled again once we have got what we are searching for.

We are very satisfied with the functionality and the launch. The entire Cluster is running absolutely stable. This is a significant advantage for our customers because we are able to offer our services without interruption. We will use Galera in further projects and convert our existing Master/Slave installations.

A. Rempening, Datenbank-Administrator, KiKxxl GmbH

Download this case study: KiKxxl Gmbh: Highly available communication services based on a MySQL database and Galera Cluster (PDF, 420 kbyte).

Taxonomy upgrade extras: galeraclustercustomer

We are very satisfied with the functionality and the launch. The entire Cluster is running absolutely stable. This is a significant advantage for our customers because we are able to offer our services without interruption. We will use Galera in further projects and convert our existing Master/Slave installations.

A. Rempening, Datenbank-Administrator, KiKxxl GmbH

Download this case study: KiKxxl Gmbh: Highly available communication services based on a MySQL database and Galera Cluster (PDF, 420 kbyte).

Taxonomy upgrade extras: galeraclustercustomer

Taxonomy upgrade extras: galeraclustercustomer

We are very satisfied with the functionality and the launch. The entire Cluster is running absolutely stable. This is a significant advantage for our customers because we are able to offer our services without interruption. We will use Galera in further projects and convert our existing Master/Slave installations.

A. Rempening, Datenbank-Administrator, KiKxxl GmbH

Download this case study: KiKxxl Gmbh: Highly available communication services based on a MySQL database and Galera Cluster (PDF, 420 kbyte).

Wir sind mit der Funktionalität und der Einführung sehr zufrieden. Das gesamte Cluster läuft absolut stabil. Dies ist ein erheblicher Vorteil für unseren Kunden denn wir können unsere Dienstleistungen unterbrechungsfrei anbieten. Wir werden Galera bei weiteren Projekten einsetzen und bestehende Master/Slave-Anwendungen umstellen.

A. Rempening, Datenbank-Administrator, KiKxxl GmbH

Den Referenzbericht können Sie hier herunterladen: KiKxxl Gmbh: Hochverfügbare Kommunikationsservices auf Basis der MySQL Datenbank und Galera Cluster (PDF, 420 kbyte).

Taxonomy upgrade extras: galeraclustercustomer

Wir sind mit der Funktionalität und der Einführung sehr zufrieden. Das gesamte Cluster läuft absolut stabil. Dies ist ein erheblicher Vorteil für unseren Kunden denn wir können unsere Dienstleistungen unterbrechungsfrei anbieten. Wir werden Galera bei weiteren Projekten einsetzen und bestehende Master/Slave-Anwendungen umstellen.

A. Rempening, Datenbank-Administrator, KiKxxl GmbH

Den Referenzbericht können Sie hier herunterladen: KiKxxl Gmbh: Hochverfügbare Kommunikationsservices auf Basis der MySQL Datenbank und Galera Cluster (PDF, 420 kbyte).

Taxonomy upgrade extras: galeraclustercustomer

Taxonomy upgrade extras: galeraclustercustomer

Wir sind mit der Funktionalität und der Einführung sehr zufrieden. Das gesamte Cluster läuft absolut stabil. Dies ist ein erheblicher Vorteil für unseren Kunden denn wir können unsere Dienstleistungen unterbrechungsfrei anbieten. Wir werden Galera bei weiteren Projekten einsetzen und bestehende Master/Slave-Anwendungen umstellen.

A. Rempening, Datenbank-Administrator, KiKxxl GmbH

Den Referenzbericht können Sie hier herunterladen: KiKxxl Gmbh: Hochverfügbare Kommunikationsservices auf Basis der MySQL Datenbank und Galera Cluster (PDF, 420 kbyte).

Das Programm für den DOAG SIG MySQL Tag in Berlin steht jetzt fest: http://www.doag.org/termine/termine.php?tid=477934

Unternehmen aus der Berliner IT Szene zeigen, wie Sie ihre Probleme mit MySQL lösen.

Anmeldung hier: https://www.doag.org/termine/anmeldung.php?tid=477934

Das Programm für den DOAG SIG MySQL Tag in Berlin steht jetzt fest: http://www.doag.org/termine/termine.php?tid=477934

Unternehmen aus der Berliner IT Szene zeigen, wie Sie ihre Probleme mit MySQL lösen.

Anmeldung hier: https://www.doag.org/termine/anmeldung.php?tid=477934

Das Programm für den DOAG SIG MySQL Tag in Berlin steht jetzt fest: http://www.doag.org/termine/termine.php?tid=477934

Unternehmen aus der Berliner IT Szene zeigen, wie Sie ihre Probleme mit MySQL lösen.

Anmeldung hier: https://www.doag.org/termine/anmeldung.php?tid=477934

Am Montag, 17. und Dienstag 18. März 2014 findet im Linux-Hotel in Essen eine Galera-Cluster Schulung statt. Die Schulung wird mit Sicherheit durchgeführt werden, da die minimale Teilnehmerzahl bereits erreicht ist.

Falls Sie Interesse haben, an dieser Schulung teilzunehmen, bitten wir Sie, Sich rechtzeitig anzumelden, um Sich Ihren Platz zu sichern.

Anmelden für die Galera Cluster Schulung können Sie Sich hier.

Vom 7. bis 11. April findet eine weitere Schulung MySQL für Profis in Berlin statt.

Bitte vermerken Sie unter Anmerkungen, dass Sie über den FromDual Newsletter auf das Angebot aufmerksam gemacht wurden.

Alle übrigen Schulungstermine finden Sie unter MySQL Schulung.

Taxonomy upgrade extras: galeraclusterschulung

Am Montag, 17. und Dienstag 18. März 2014 findet im Linux-Hotel in Essen eine Galera-Cluster Schulung statt. Die Schulung wird mit Sicherheit durchgeführt werden, da die minimale Teilnehmerzahl bereits erreicht ist.

Falls Sie Interesse haben, an dieser Schulung teilzunehmen, bitten wir Sie, Sich rechtzeitig anzumelden, um Sich Ihren Platz zu sichern.

Anmelden für die Galera Cluster Schulung können Sie Sich hier.

Vom 7. bis 11. April findet eine weitere Schulung MySQL für Profis in Berlin statt.

Bitte vermerken Sie unter Anmerkungen, dass Sie über den FromDual Newsletter auf das Angebot aufmerksam gemacht wurden.

Alle übrigen Schulungstermine finden Sie unter MySQL Schulung.

Taxonomy upgrade extras: galeraclusterschulung

Taxonomy upgrade extras: galeraclusterschulung

Am Montag, 17. und Dienstag 18. März 2014 findet im Linux-Hotel in Essen eine Galera-Cluster Schulung statt. Die Schulung wird mit Sicherheit durchgeführt werden, da die minimale Teilnehmerzahl bereits erreicht ist.

Falls Sie Interesse haben, an dieser Schulung teilzunehmen, bitten wir Sie, Sich rechtzeitig anzumelden, um Sich Ihren Platz zu sichern.

Anmelden für die Galera Cluster Schulung können Sie Sich hier.

Vom 7. bis 11. April findet eine weitere Schulung MySQL für Profis in Berlin statt.

Bitte vermerken Sie unter Anmerkungen, dass Sie über den FromDual Newsletter auf das Angebot aufmerksam gemacht wurden.

Alle übrigen Schulungstermine finden Sie unter MySQL Schulung.

im letzten Newsletter haben wir Sie über die FromDual Beratungs-Dienstleistungen informiert. Fokus waren die Verfügbarkeit und die Vermeidung von Ausfällen der MySQL Datenbank (Welche Kosten verursacht eine Stunde Ausfallzeit Ihrer MySQL Datenbank?).

Heute möchten wir uns auf Hardwareperformance und somit auch auf Applikationsperformance konzentrieren. Wir zeigen Ihnen zwei Möglichkeiten auf, wie Sie mit Ihrer MySQL-Anwendung schneller werden und haben interessante Angebote für Sie. Im Januar 2014 ist FromDual Virident (Western Digital HGST) Partner geworden und hat damit die Möglichkeit für erhöhte Performance-Anforderungen Ihre vorhandenen Server auch mit PCIe Flash-Karten auszustatten und so nicht mehr auf langsame Platten angewiesen zu sein.

Beschleunigen Sie Ihre MySQL Datenbanken mit unserer Hilfe:

1. Performance Tuning und Optimierung der MySQL Datenbank durch:
   • Überwachung der Datenbank mit dem MySQL Performance Monitor,
   • eine Datenbank-Konfigurationsanalyse mit unserer Frageliste: dem MySQL Performance Tuning Schlüssel, einer Anleitung zum identifizieren von Performance Problemen und zu deren Behebung,
   • sowie dem MySQL Gesundheits-Check.
   
   
2. Performance Tuning der I/O-Raten und der Plattenzugriffe mit neuester Hardware von Virident.

Wir stellen Ihnen ein Paket für MySQL Turbo Performance vor, bestehend aus der PCIe Flash-Einsteckkarte FlashMaxII und einem Architektur-Consulting für die optimale Anpassung der MySQL Datenbank an die Flash-Karten.

Hier ein Performancevergleich zwischen konventionellen RAID-10 Platten und Virident Flash-Karten:

Spezial-Angebot 1: PCIe Einsteckkarte FlashMaxII MLC mit 550 GByte Kapazität

Inklusive 2 Tage FromDual remote Consulting für die Unterstützung bei der Inbetriebnahme und der Optimierung der Datenbankanwendung für eine optimale Nutzung der Flash-Karten.

Hilfestellung erfolgt bei:

• der Konfiguration des Linux Kernels,
• der Optimierung der Treiber,
• der Konfigurierung des Laufwerks,
• der Konfigurierung der MySQL Parameter für die Datenbank-Caches, Log-File Grössen, etc.
• sowie weiterer Tuning-Tipps bezüglich MySQL, MariaDB oder Percona Server.

Preis für eine Karte und 2 Tage FromDual remote-Consulting: EUR 4'990.-

Spezial-Angebot 2: PCIe Einsteckkarte FlashMaxII MLC mit 550 GByte Kapazität

Inklusive 1 Tag FromDual remote Consulting für die Unterstützung bei der Inbetriebnahme und der Optimierung der Datenbankanwendung für eine optimale Nutzung des Flash-Karten.

Hilfestellung erfolgt bei:

• der Konfigurierung der MySQL Parameter für die Datenbank-Caches, Log-File Grössen, etc.
• sowie weiterer Tuning-Tipps bezüglich MySQL, MariaDB oder Percona Server.

Bei diesem Angebot muss die PCIe-Karte selber eingebaut, Linux konfiguriert und das Filesystem für die Nutzung der Flash-Karten aufgesetzt sein. Die Leistungserbringung beschränkt sich auf die Konfiguration der MySQL Datenbank.

Preis für eine Karte und 1 Tag FromDual remote-Consulting: EUR 3'990.-

FlashMaxII ist verfügbar in weiteren Konfigurationen und Grössen. Diese finden Sie auf der Virident Webseite.

Den Support für Ihre MySQL-Datenbank erhalten Sie von FromDual, denjenigen für die Flash-Karten direkt bei Virident.

Gerne erstellen wir Ihnen ein Spezial-Angebot für unsere Leistungen in Verbindung mit weiteren FlashMaxII Konfigurationen.

Wir freuen uns, mehr von Ihnen zu hören.

Taxonomy upgrade extras: mysqlperformanceflashssdvirident

im letzten Newsletter haben wir Sie über die FromDual Beratungs-Dienstleistungen informiert. Fokus waren die Verfügbarkeit und die Vermeidung von Ausfällen der MySQL Datenbank (Welche Kosten verursacht eine Stunde Ausfallzeit Ihrer MySQL Datenbank?).

Heute möchten wir uns auf Hardwareperformance und somit auch auf Applikationsperformance konzentrieren. Wir zeigen Ihnen zwei Möglichkeiten auf, wie Sie mit Ihrer MySQL-Anwendung schneller werden und haben interessante Angebote für Sie. Im Januar 2014 ist FromDual Virident (Western Digital HGST) Partner geworden und hat damit die Möglichkeit für erhöhte Performance-Anforderungen Ihre vorhandenen Server auch mit PCIe Flash-Karten auszustatten und so nicht mehr auf langsame Platten angewiesen zu sein.

Beschleunigen Sie Ihre MySQL Datenbanken mit unserer Hilfe:

1. Performance Tuning und Optimierung der MySQL Datenbank durch:
   • Überwachung der Datenbank mit dem MySQL Performance Monitor,
   • eine Datenbank-Konfigurationsanalyse mit unserer Frageliste: dem MySQL Performance Tuning Schlüssel, einer Anleitung zum identifizieren von Performance Problemen und zu deren Behebung,
   • sowie dem MySQL Gesundheits-Check.
   
   
2. Performance Tuning der I/O-Raten und der Plattenzugriffe mit neuester Hardware von Virident.

Wir stellen Ihnen ein Paket für MySQL Turbo Performance vor, bestehend aus der PCIe Flash-Einsteckkarte FlashMaxII und einem Architektur-Consulting für die optimale Anpassung der MySQL Datenbank an die Flash-Karten.

Hier ein Performancevergleich zwischen konventionellen RAID-10 Platten und Virident Flash-Karten:

Spezial-Angebot 1: PCIe Einsteckkarte FlashMaxII MLC mit 550 GByte Kapazität

Inklusive 2 Tage FromDual remote Consulting für die Unterstützung bei der Inbetriebnahme und der Optimierung der Datenbankanwendung für eine optimale Nutzung der Flash-Karten.

Hilfestellung erfolgt bei:

• der Konfiguration des Linux Kernels,
• der Optimierung der Treiber,
• der Konfigurierung des Laufwerks,
• der Konfigurierung der MySQL Parameter für die Datenbank-Caches, Log-File Grössen, etc.
• sowie weiterer Tuning-Tipps bezüglich MySQL, MariaDB oder Percona Server.

Preis für eine Karte und 2 Tage FromDual remote-Consulting: EUR 4'990.-

Spezial-Angebot 2: PCIe Einsteckkarte FlashMaxII MLC mit 550 GByte Kapazität

Inklusive 1 Tag FromDual remote Consulting für die Unterstützung bei der Inbetriebnahme und der Optimierung der Datenbankanwendung für eine optimale Nutzung des Flash-Karten.

Hilfestellung erfolgt bei:

• der Konfigurierung der MySQL Parameter für die Datenbank-Caches, Log-File Grössen, etc.
• sowie weiterer Tuning-Tipps bezüglich MySQL, MariaDB oder Percona Server.

Bei diesem Angebot muss die PCIe-Karte selber eingebaut, Linux konfiguriert und das Filesystem für die Nutzung der Flash-Karten aufgesetzt sein. Die Leistungserbringung beschränkt sich auf die Konfiguration der MySQL Datenbank.

Preis für eine Karte und 1 Tag FromDual remote-Consulting: EUR 3'990.-

FlashMaxII ist verfügbar in weiteren Konfigurationen und Grössen. Diese finden Sie auf der Virident Webseite.

Den Support für Ihre MySQL-Datenbank erhalten Sie von FromDual, denjenigen für die Flash-Karten direkt bei Virident.

Gerne erstellen wir Ihnen ein Spezial-Angebot für unsere Leistungen in Verbindung mit weiteren FlashMaxII Konfigurationen.

Wir freuen uns, mehr von Ihnen zu hören.

Taxonomy upgrade extras: mysqlperformanceflashssdvirident

Taxonomy upgrade extras: mysqlperformanceflashssdvirident

im letzten Newsletter haben wir Sie über die FromDual Beratungs-Dienstleistungen informiert. Fokus waren die Verfügbarkeit und die Vermeidung von Ausfällen der MySQL Datenbank (Welche Kosten verursacht eine Stunde Ausfallzeit Ihrer MySQL Datenbank?).

Heute möchten wir uns auf Hardwareperformance und somit auch auf Applikationsperformance konzentrieren. Wir zeigen Ihnen zwei Möglichkeiten auf, wie Sie mit Ihrer MySQL-Anwendung schneller werden und haben interessante Angebote für Sie. Im Januar 2014 ist FromDual Virident (Western Digital HGST) Partner geworden und hat damit die Möglichkeit für erhöhte Performance-Anforderungen Ihre vorhandenen Server auch mit PCIe Flash-Karten auszustatten und so nicht mehr auf langsame Platten angewiesen zu sein.

Beschleunigen Sie Ihre MySQL Datenbanken mit unserer Hilfe:

1. Performance Tuning und Optimierung der MySQL Datenbank durch:
   • Überwachung der Datenbank mit dem MySQL Performance Monitor,
   • eine Datenbank-Konfigurationsanalyse mit unserer Frageliste: dem MySQL Performance Tuning Schlüssel, einer Anleitung zum identifizieren von Performance Problemen und zu deren Behebung,
   • sowie dem MySQL Gesundheits-Check.
   
   
2. Performance Tuning der I/O-Raten und der Plattenzugriffe mit neuester Hardware von Virident.

Wir stellen Ihnen ein Paket für MySQL Turbo Performance vor, bestehend aus der PCIe Flash-Einsteckkarte FlashMaxII und einem Architektur-Consulting für die optimale Anpassung der MySQL Datenbank an die Flash-Karten.

Hier ein Performancevergleich zwischen konventionellen RAID-10 Platten und Virident Flash-Karten:

Spezial-Angebot 1: PCIe Einsteckkarte FlashMaxII MLC mit 550 GByte Kapazität

Inklusive 2 Tage FromDual remote Consulting für die Unterstützung bei der Inbetriebnahme und der Optimierung der Datenbankanwendung für eine optimale Nutzung der Flash-Karten.

Hilfestellung erfolgt bei:

• der Konfiguration des Linux Kernels,
• der Optimierung der Treiber,
• der Konfigurierung des Laufwerks,
• der Konfigurierung der MySQL Parameter für die Datenbank-Caches, Log-File Grössen, etc.
• sowie weiterer Tuning-Tipps bezüglich MySQL, MariaDB oder Percona Server.

Preis für eine Karte und 2 Tage FromDual remote-Consulting: EUR 4'990.-

Spezial-Angebot 2: PCIe Einsteckkarte FlashMaxII MLC mit 550 GByte Kapazität

Inklusive 1 Tag FromDual remote Consulting für die Unterstützung bei der Inbetriebnahme und der Optimierung der Datenbankanwendung für eine optimale Nutzung des Flash-Karten.

Hilfestellung erfolgt bei:

• der Konfigurierung der MySQL Parameter für die Datenbank-Caches, Log-File Grössen, etc.
• sowie weiterer Tuning-Tipps bezüglich MySQL, MariaDB oder Percona Server.

Bei diesem Angebot muss die PCIe-Karte selber eingebaut, Linux konfiguriert und das Filesystem für die Nutzung der Flash-Karten aufgesetzt sein. Die Leistungserbringung beschränkt sich auf die Konfiguration der MySQL Datenbank.

Preis für eine Karte und 1 Tag FromDual remote-Consulting: EUR 3'990.-

FlashMaxII ist verfügbar in weiteren Konfigurationen und Grössen. Diese finden Sie auf der Virident Webseite.

Den Support für Ihre MySQL-Datenbank erhalten Sie von FromDual, denjenigen für die Flash-Karten direkt bei Virident.

Gerne erstellen wir Ihnen ein Spezial-Angebot für unsere Leistungen in Verbindung mit weiteren FlashMaxII Konfigurationen.

Wir freuen uns, mehr von Ihnen zu hören.

One of the most expensive database operations is performing Data Definition Language (DDL, e.g. CREATE, DROP, ALTER, etc.) statements, specially, the ALTER statements because MySQL blocks the entire table for both reads and writes while modifying the table.

For the huge tables, this might take hours to get the table changed which affects the application, so that, a good planning is required for such operations in order to avoid doing these changes during the peak times. For those people who have 24/7 services or limited maintenance window, DDL on huge tables is a really nightmare.

Percona developed a very good tool called pt-online-schema-change (version 2.2.6 at the time of writing this article) to perform such operations online without blocking/affecting the application and read/write operations to the table being changed is available.
Also MySQL made some enhancements for DDL statements and introduced the Online DDL feature in MySQL 5.6.

In this article, I will talk about an overview of both ways (Online DDL & pt-online-schema-change) alongside with an example and which one of them should be used in different scenarios.

pt-online-schema-change Overview

This tool is developed by Percona to alter tables without locking them during the ALTER operation.
Simply, this tool creates a new empty table like the original table with the needed structure change, copy the data from the original table in small chunks to the new table, drop the original table and then rename the new table to the original name. During the copy process all new changes to the original table are being applied to the new one because a trigger is created on the original table which ensure that all new changes will be applied on the new table.

For more information about pt-online-schema-change tool, check out the manual documentation.

Example

Altering a table called "test.test1" by adding an index (name_idx) on column "name":

[root@gcservera ~]# pt-online-schema-change --execute --alter "add index name_idx (name)" D=test,t=test1,h=localhost Operation, tries, wait: copy_rows, 10, 0.25 create_triggers, 10, 1 drop_triggers, 10, 1 swap_tables, 10, 1 update_foreign_keys, 10, 1 Altering `test`.`test1`... Creating new table... Created new table test._test1_new OK. Altering new table... Altered `test`.`_test1_new` OK. 2014-02-09T15:33:27 Creating triggers... 2014-02-09T15:33:27 Created triggers OK. 2014-02-09T15:33:27 Copying approximately 1 rows... 2014-02-09T15:33:27 Copied rows OK. 2014-02-09T15:33:27 Swapping tables... 2014-02-09T15:33:27 Swapped original and new tables OK. 2014-02-09T15:33:27 Dropping old table... 2014-02-09T15:33:27 Dropped old table `test`.`_test1_old` OK. 2014-02-09T15:33:27 Dropping triggers... 2014-02-09T15:33:27 Dropped triggers OK. Successfully altered `test`.`test1`.

Note:

The output is perfectly describing all steps that the tool is doing in the background.

Limitations of pt-online-schema-change

• A PRIMARY KEY or a unique index should be defined for the table before using this tool because it is required for the DELETE trigger.
• Not supported if the table has already triggers defined.
• The tool become complicate a little if the table has a foreign key constraint and an additional option --alter-foreign-keys-method should be used.
• Also because of the foreign keys, the object names might be changed (indexes names , .. etc).
• In Galera Cluster environment, altering MyISAM tables is not supported and the system variable "wsrep_OSU_method" must be set to "TOI" (total order isolation).

Online DDL Overview

In MySQL 5.5 and 5.1 with the InnoDB plugin, a new feature known as Fast Index Creation was introduced to avoid copying the tables data - when adding or removing secondary indexes - using the optimized CREATE INDEX and DROP INDEX statements.

In MySQL 5.6, the Online DDL method was introduced to allow more changes to be made on the table while accessing and writing to the table being changed is available.

The Online DDL syntax is exactly the same like the normal alter statement after specifying two parameters:

ALGORITHM:

• INPLACE: the table change will be made in-place without rebuilding the entire table (in most cases, no copying data to temporary table is required).
• COPY: copying data to a temporary table, rebuilding the table and reconstructing the secondary indexes will be made (equivalent to the traditional method).

LOCK:

• NONE: Read and write operations are allowed during the altering process.
• SHARED: Only read operations are allowed during the altering operations (DML is not allowed).
• EXCLUSIVE: The entire table will be locked for both reading and writing (neither select nor DML are allowed).

The Online DDL is perfectly explained in the online manual documentation, you can check it out here for more information.

Example

Altering a table called "test.test2" by adding an index (name_idx) on column "name":

mysql> alter table test2 -> add index name_idx (name),algorithm=inplace, lock=none; Query OK, 0 rows affected (0.03 sec) Records: 0 Duplicates: 0 Warnings: 0 Limitations of Online DDL

• Works only with InnoDB (syntax wise it could be used with other storage engines "like MyISAM" but only "algorithm=copy" is allowed which is equivalent to the traditional method).
• Regardless of the locking used (none,shared or exclusive) a brief period at the beginning and at the end of the process is requiring an exclusive lock on the table.
• foreign_key_checks should be disabled when adding/dropping foreign keys to avoid table copying behavior.
• Still some alter operations require table copying or table locking in order to make the change (the old behavior). For more details on which table change require table-copying or table locking, check out this manual page.
• LOCK=NONE is not allowed in the alter table statement if there are ON...CASCADE or ON...SET NULL constraints on the table.
• While the Online DDL will be replicated on the slaves the same like the master (if LOCK=NONE no table-locking will take place on the slaves during the alter execution) but the replication itself will be blocked as the replay process executes in a single thread on the replicas which will cause slave lagging problem.

Comparison results

The following is a comparison results between Online DDL and pt-online-schema-change for some alter operations applied on a table contains 1,078,880 rows:

Online DDLpt-online-schema-changeChange OperationRow(s) affectedIs table locked?Time (sec)Row(s) affectedIs table locked?Time (sec)Add Index0No3.76All rowsNo38.12Drop Index0No0.34All rowsNo36.04Add Column0No27.61All rowsNo37.21Rename Column0No0.06All rowsNo34.16Rename Column + change its data typeAll rowsYes30.21All rowsNo34.23Drop Column0No22.41All rowsNo31.57Change table ENGINEAll rowsYes25.30All rowsNo35.54Which method should be used?

Now the question is, which method should we use to perform alter table statements?

While pt-online-schema-change allows read and write operations to the table being altered, it still copies the tables data to a temporary table in the background which adds overhead on the MySQL server. So basically, we should use pt-online-schema-change if the Online DDL will not work efficiently. In other words, if the Online DDL will require copying data to a temporary table (algorithm=copy) and the table will be blocked for long time (lock=exclusive) or when altering huge tables in a replication environment then we should use pt-online-schema-change tool.

One of the most expensive database operations is performing Data Definition Language (DDL, e.g. CREATE, DROP, ALTER, etc.) statements, specially, the ALTER statements because MySQL blocks the entire table for both reads and writes while modifying the table.

For the huge tables, this might take hours to get the table changed which affects the application, so that, a good planning is required for such operations in order to avoid doing these changes during the peak times. For those people who have 24/7 services or limited maintenance window, DDL on huge tables is a really nightmare.

Percona developed a very good tool called pt-online-schema-change (version 2.2.6 at the time of writing this article) to perform such operations online without blocking/affecting the application and read/write operations to the table being changed is available.
Also MySQL made some enhancements for DDL statements and introduced the Online DDL feature in MySQL 5.6.

In this article, I will talk about an overview of both ways (Online DDL & pt-online-schema-change) alongside with an example and which one of them should be used in different scenarios.

pt-online-schema-change Overview

This tool is developed by Percona to alter tables without locking them during the ALTER operation.
Simply, this tool creates a new empty table like the original table with the needed structure change, copy the data from the original table in small chunks to the new table, drop the original table and then rename the new table to the original name. During the copy process all new changes to the original table are being applied to the new one because a trigger is created on the original table which ensure that all new changes will be applied on the new table.

For more information about pt-online-schema-change tool, check out the manual documentation.

Example

Altering a table called "test.test1" by adding an index (name_idx) on column "name":

[root@gcservera ~]# pt-online-schema-change --execute --alter "add index name_idx (name)" D=test,t=test1,h=localhost Operation, tries, wait: copy_rows, 10, 0.25 create_triggers, 10, 1 drop_triggers, 10, 1 swap_tables, 10, 1 update_foreign_keys, 10, 1 Altering `test`.`test1`... Creating new table... Created new table test._test1_new OK. Altering new table... Altered `test`.`_test1_new` OK. 2014-02-09T15:33:27 Creating triggers... 2014-02-09T15:33:27 Created triggers OK. 2014-02-09T15:33:27 Copying approximately 1 rows... 2014-02-09T15:33:27 Copied rows OK. 2014-02-09T15:33:27 Swapping tables... 2014-02-09T15:33:27 Swapped original and new tables OK. 2014-02-09T15:33:27 Dropping old table... 2014-02-09T15:33:27 Dropped old table `test`.`_test1_old` OK. 2014-02-09T15:33:27 Dropping triggers... 2014-02-09T15:33:27 Dropped triggers OK. Successfully altered `test`.`test1`.

Note:

The output is perfectly describing all steps that the tool is doing in the background.

Limitations of pt-online-schema-change

• A PRIMARY KEY or a unique index should be defined for the table before using this tool because it is required for the DELETE trigger.
• Not supported if the table has already triggers defined.
• The tool become complicate a little if the table has a foreign key constraint and an additional option --alter-foreign-keys-method should be used.
• Also because of the foreign keys, the object names might be changed (indexes names , .. etc).
• In Galera Cluster environment, altering MyISAM tables is not supported and the system variable "wsrep_OSU_method" must be set to "TOI" (total order isolation).

Online DDL Overview

In MySQL 5.5 and 5.1 with the InnoDB plugin, a new feature known as Fast Index Creation was introduced to avoid copying the tables data - when adding or removing secondary indexes - using the optimized CREATE INDEX and DROP INDEX statements.

In MySQL 5.6, the Online DDL method was introduced to allow more changes to be made on the table while accessing and writing to the table being changed is available.

The Online DDL syntax is exactly the same like the normal alter statement after specifying two parameters:

ALGORITHM:

• INPLACE: the table change will be made in-place without rebuilding the entire table (in most cases, no copying data to temporary table is required).
• COPY: copying data to a temporary table, rebuilding the table and reconstructing the secondary indexes will be made (equivalent to the traditional method).

LOCK:

• NONE: Read and write operations are allowed during the altering process.
• SHARED: Only read operations are allowed during the altering operations (DML is not allowed).
• EXCLUSIVE: The entire table will be locked for both reading and writing (neither select nor DML are allowed).

The Online DDL is perfectly explained in the online manual documentation, you can check it out here for more information.

Example

Altering a table called "test.test2" by adding an index (name_idx) on column "name":

mysql> alter table test2 -> add index name_idx (name),algorithm=inplace, lock=none; Query OK, 0 rows affected (0.03 sec) Records: 0 Duplicates: 0 Warnings: 0 Limitations of Online DDL

• Works only with InnoDB (syntax wise it could be used with other storage engines "like MyISAM" but only "algorithm=copy" is allowed which is equivalent to the traditional method).
• Regardless of the locking used (none,shared or exclusive) a brief period at the beginning and at the end of the process is requiring an exclusive lock on the table.
• foreign_key_checks should be disabled when adding/dropping foreign keys to avoid table copying behavior.
• Still some alter operations require table copying or table locking in order to make the change (the old behavior). For more details on which table change require table-copying or table locking, check out this manual page.
• LOCK=NONE is not allowed in the alter table statement if there are ON...CASCADE or ON...SET NULL constraints on the table.
• While the Online DDL will be replicated on the slaves the same like the master (if LOCK=NONE no table-locking will take place on the slaves during the alter execution) but the replication itself will be blocked as the replay process executes in a single thread on the replicas which will cause slave lagging problem.

Comparison results

The following is a comparison results between Online DDL and pt-online-schema-change for some alter operations applied on a table contains 1,078,880 rows:

Online DDLpt-online-schema-changeChange OperationRow(s) affectedIs table locked?Time (sec)Row(s) affectedIs table locked?Time (sec)Add Index0No3.76All rowsNo38.12Drop Index0No0.34All rowsNo36.04Add Column0No27.61All rowsNo37.21Rename Column0No0.06All rowsNo34.16Rename Column + change its data typeAll rowsYes30.21All rowsNo34.23Drop Column0No22.41All rowsNo31.57Change table ENGINEAll rowsYes25.30All rowsNo35.54Which method should be used?

Now the question is, which method should we use to perform alter table statements?

While pt-online-schema-change allows read and write operations to the table being altered, it still copies the tables data to a temporary table in the background which adds overhead on the MySQL server. So basically, we should use pt-online-schema-change if the Online DDL will not work efficiently. In other words, if the Online DDL will require copying data to a temporary table (algorithm=copy) and the table will be blocked for long time (lock=exclusive) or when altering huge tables in a replication environment then we should use pt-online-schema-change tool.