Agrégateur de flux

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.

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.

Hallo zusammen,

Matthias Jung und ich planen dieses Jahr 2 SIG MySQL Events durchzuführen. Eins am Donnerstag 27. März und eins am Dienstag 30. September.

Eine grobe Idee ist, ein Event in Berlin und eines in Raum Köln/Düsseldorf durchzuführen.

Was wir jetzt noch bräuchten sind Referenten! Wer von Euch hätte Lust und v.a. Zeit 27. März einen Vortrag (ca 45 min) zum Thema MySQL Operations/Betrieb zu halten? Auch Berichte aus der Praxis sind sehr willkommen. Wer mag, kann also auch einen Kunden dazu veranlassen.

Bitte mit Ideen bei mir melden.

Hallo zusammen,

Matthias Jung und ich planen dieses Jahr 2 SIG MySQL Events durchzuführen. Eins am Donnerstag 27. März und eins am Dienstag 30. September.

Eine grobe Idee ist, ein Event in Berlin und eines in Raum Köln/Düsseldorf durchzuführen.

Was wir jetzt noch bräuchten sind Referenten! Wer von Euch hätte Lust und v.a. Zeit 27. März einen Vortrag (ca 45 min) zum Thema MySQL Operations/Betrieb zu halten? Auch Berichte aus der Praxis sind sehr willkommen. Wer mag, kann also auch einen Kunden dazu veranlassen.

Bitte mit Ideen bei mir melden.

Hallo zusammen,

Matthias Jung und ich planen dieses Jahr 2 SIG MySQL Events durchzuführen. Eins am Donnerstag 27. März und eins am Dienstag 30. September.

Eine grobe Idee ist, ein Event in Berlin und eines in Raum Köln/Düsseldorf durchzuführen.

Was wir jetzt noch bräuchten sind Referenten! Wer von Euch hätte Lust und v.a. Zeit 27. März einen Vortrag (ca 45 min) zum Thema MySQL Operations/Betrieb zu halten? Auch Berichte aus der Praxis sind sehr willkommen. Wer mag, kann also auch einen Kunden dazu veranlassen.

Bitte mit Ideen bei mir melden.

Taxonomy upgrade extras: mysqlperformancePerformance Tuningqueryquery tuningtuningMySQL single query performance - the truth!

As suggested by morgo I did a little test for the same query and the same data-set mentioned in Impact of column types on MySQL JOIN performance but looking into an other dimension: the time (aka MySQL versions).

The answer

To make it short. As a good consultant the answer must be: "It depends!" :-)

The test

The query was again the following:

SELECT * FROM a JOIN b ON b.a_id = a.id WHERE a.id BETWEEN 10000 AND 15000 ;

The Query Execution Plan was the same for all tested releases.

The relevant MySQL variables where used as follows where possible. Should I have considered join buffer, or any other of those local per session buffers (read_buffer_size, read_rnd_buffer_size, join_buffer_size)?

innodb_buffer_pool_size = 768M innodb_buffer_pool_instances = 1 innodb_file_per_table = 1
The results mysql-4.0.30mysql-4.1.25mysql-5.0.96mysql-5.1.73mysql-5.5.35mysql-5.6.15mysql-5.7.3AVG40.8638.683.714.694.647.226.05MEDIAN41.0738.133.694.464.656.326.05STDEV1.512.260.060.340.032.210.03MIN39.2736.993.674.404.596.266.02MAX44.1144.453.865.234.6713.166.10COUNT10.0010.0010.0010.0010.0010.0010.00
mariadb-5.1.44mariadb-5.2.10mariadb-5.3.3mariadb-5.5.34mariadb-10.0.6AVG4.588.638.345.026.12MEDIAN4.587.978.015.026.01STDEV0.011.451.100.020.25MIN4.557.867.904.995.97MAX4.6011.3811.465.066.75COUNT10.0010.0010.0010.0010.00
percona-5.0.92-23.85percona-5.1.72-14.10percona-5.5.34-32.0percona-5.6.14-62.0AVG3.794.704.9410.53MEDIAN3.794.704.8912.41STDEV0.020.030.143.35MIN3.764.674.865.68MAX3.834.755.3412.93COUNT10.0010.0010.0010.00
galera-5.5.33-23.7.6 / 2.7AVG4.31MEDIAN3.98STDEV1.18MIN3.76MAX8.54COUNT30.00
The Graph

Conclusion

Do not trust benchmarks. They are mostly worthless for your specific workload and pure marketing buzz... Including the one above! ;-)

Database vendors (Oracle/MySQL, Percona, MariaDB) are primarily focussing on throughput and features. In general this is at the costs of single query performance.
MySQL users like Facebook, LinkedIn, Google, Wikpedia, Booking.com, Yahoo! etc. are more interested in throughput than single query performance (so I assume). But most of the MySQL users (95%) do not have a troughput problem but a single query performance problem (I assume here that this is true also for Oracle, MS-SQL Server, DB2, PostgreSQL, etc.).

So database vendors are not primarily producing for the masses but for some specific users/customers (which possibly pay a hell of money for this).

Back to the data:

My first hypothesis: "The old times were always better" is definitely not true. MySQL 4.0 and 4.1 sucked with this specific query. But since MySQL 5.0 the rough trend is: single query performance becomes worse over time (newer versions). I assume this also true for other databases...

Some claims like: "We have the fastest MySQL" or "We have hired the whole optimizer team" does not necessary reflect in better single query performance. At least not for this specific query.

So in short: If you upgrade or side-grade (MySQL <-> Percona <-> MariaDB), test always very carefully! It is not predictable where the traps are. Newer MySQL release can increase performance of your application or not. Do not trust marketing buzz!

Artefacts

Some artefacts we have already found during this tiny test:

• In MySQL 5.0 an optimization was introduced (not in the Optimizer!?!) to speed up this specific query dramatically.
• MariaDB 5.2 and 5.3 were bad for this specific query.
• I have no clue why Galera Cluster has shown the best results for 5.5. It is no intention or manipulation! It is poor luck. But I like it! :-)
• MySQL 5.6 seems to have some problems with this query. To much improvement done by Oracle/MySQL?
• Percona 5.6 sometimes behaves much better with this query than normal MySQL but from time to time something kicks in which makes Percona dramatically slower. Thus the bad results. I have no clue why. I first though about an external influence. But I was capable to reproduce this behaviour (once). So I assume it must be something Percona internally (AHI for example?).

Finally

Do not shoot the messenger!

If you want to reproduce the results most information about are already published. If something is missing please let me know.

Please let me know when you do not agree with the results. So I can expand my universe a bit...

It was fun doing this tests today! And MyEnv was a great assistance doing this kind of tests!

If you want us to do such test for you, please let us know. Our consulting team would be happy to assist you with upgrading or side-grading problems.