Feed aggregator

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.

Taxonomy upgrade extras: sqlquerytuningmysql

In our MySQL trainings and consulting engagements we tell our customers always to use the smallest possible data type to get better query performance. Especially for the JOIN columns. This advice is supported as well by the MySQL documentation in the chapter Optimizing Data Types:

Use the most efficient (smallest) data types possible. MySQL has many specialized types that save disk space and memory. For example, use the smaller integer types if possible to get smaller tables. MEDIUMINT is often a better choice than INT because a MEDIUMINT column uses 25% less space.

I remember somewhere the JOIN columns where explicitly mentioned but I cannot find it any more.

Test set-up

To get numbers we have created a little test set-up:

CREATE TABLE `a` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT , `data` varchar(64) DEFAULT NULL , `ts` timestamp NOT NULL , PRIMARY KEY (`id`) ) ENGINE=InnoDB CHARSET=latin1  
CREATE TABLE `b` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT , `data` varchar(64) DEFAULT NULL , `ts` timestamp NOT NULL , `a_id` int(10) unsigned DEFAULT NULL , PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1
1048576 rows 16777216 rows

The following query was used for the test:

EXPLAIN SELECT * FROM a JOIN b ON b.a_id = a.id WHERE a.id BETWEEN 10000 AND 15000; +----+-------------+-------+--------+---------------+---------+---------+-------------+----------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+--------+---------------+---------+---------+-------------+----------+-------------+ | 1 | SIMPLE | b | ALL | NULL | NULL | NULL | NULL | 16322446 | Using where | | 1 | SIMPLE | a | eq_ref | PRIMARY | PRIMARY | 4 | test.b.a_id | 1 | NULL | +----+-------------+-------+--------+---------------+---------+---------+-------------+----------+-------------+

And yes: I know this query could be more optimal by setting an index on b.a_id.

Results

The whole workload was executed completely in memory and thus CPU bound (we did not want to measure the speed of our I/O system).

SEJOIN columnbytesquery timeGainSpaceCharacter setInnoDBMEDIUMINT35.28 s96%4% faster75%InnoDBINT45.48 s100%100%100%InnoDBBIGINT85.65 s107%7% slower200%InnoDBNUMERIC(7, 2)~46.77 s124%24% slower~100%InnoDBVARCHAR(7)7-86.44 s118%18% slower~200%latin1InnoDBVARCHAR(16)7-86.44 s118%18% slower~200%latin1InnoDBVARCHAR(32)7-86.42 s118%18% slower~200%latin1InnoDBVARCHAR(128)7-86.46 s118%18% slower~200%latin1InnoDBVARCHAR(256)8-96.17 s114%14% slower~225%latin1InnoDBVARCHAR(16)7-86.96 s127%27% slower~200%utf8InnoDBVARCHAR(128)7-86.82 s124%24% slower~200%utf8InnoDBCHAR(16)166.85 s125%25% slower400%latin1InnoDBCHAR(128)1289.68 s177%77% slower3200%latin1InnoDBTEXT8-910.7 s195%95% slower~225%latin1MyISAMINT43.16 s58%42% fasterTokuDBINT44.52 s82%18% faster

Some comments to the tests:

• MySQL 5.6.13 was used for most of the tests.
• TokuDB v7.1.0 was tested with MySQL 5.5.30.
• As results the optimistic cases were taken. In reality the results can be slightly worse.
• We did not take into consideration that bigger data types will eventually cause more I/O which is very slow!

Commands ALTER TABLE a CONVERT TO CHARACTER SET latin1; ALTER TABLE b CONVERT TO CHARACTER SET latin1; ALTER TABLE a MODIFY COLUMN id INT UNSIGNED NOT NULL; ALTER TABLE b MODIFY COLUMN a_id INT UNSIGNED NOT NULL;

FromDual has the pleasure to announce the release of the new version 1.0.2 of its popular multi-instance MySQL Environment MyEnv.

You can download MyEnv from here.

In the inconceivable case that you find a bug in MyEnv please report it to our Bugtracker.

Any feedback, statements and testimonials are welcome as well! Please send them to feedback@fromdual.com.

If you have questions about MyEnv we will answer them in the MyEnv forum.

Upgrade from 1.0.x to 1.0.2 # cd /home/mysql/product # tar xf /tmp/myenv-1.0.2.tar.gz # rm -f myenv # ln -s myenv-1.0.2 myenv

Add the following line to your ~/.bash_profile:

# BEGIN MyEnv # Written by the MyEnv installMyEnv.php script. . /etc/myenv/MYENV_BASE MYENV_PWD=`pwd` cd $MYENV_BASE/bin . myenv.profile up cd $MYENV_PWD # END MyEnv Changes in MyEnv 1.0.2 MyEnv

• Missing [client] section in my.cnf should not lead to error any more (Bug #95).
• profile.template removed because it is redundant to installer information.
• up removed from myenv.profile.
• Also root should be allowed to start MySQL (Bug #99).
• Status for OEM agent implemented (oem_agent.php). To activate this feature copy it from utl/oem_agent.php to plg/showMyEnvStatus/.
• Plug-in interface for showMyEnvStatus.php implemented.
• Debug information improved.
• Empty line after environment switch removed.
• One missing error line in myenv_start_stop.php was added.
• Return code in myenv_start_stop.php is nicer now.
• Difference between my.cnf and myenv.conf should be warning and not an error.
• Error messages made more precise.
• Made it more clear that MyEnv is distributed under GPL v2.
• Deleting the actual instance with MyEnv Installer should no longer confuse MyEnv (Bug #104).
• RPM packages for CentOS 6, Fedora 18 and 19, RHEL 5 and 6 are available.

MyEnv Installer

• User experience during deleting an instance improved (Bug #96).
• Deleting a running instance is not allowed. Much more verbose information about (Bug #89).
• Instance name black list added.
• Instances should be listed when change was chosen (#93).
• Replace multi-line readline output to fixed crippled output in menu selection (Bug #103).

MyEnv Utilities

• alter_engine.pl should now work for socket and port, local and remote.
• Password is not exposed any more in alter_engine.pl.
• Query bench (query_bench.phpx) added for micro bench marks.

MySQL Backup Manager

• Automated mysql_bman tests should all pass again.

Taxonomy upgrade extras: myenvoperationMySQL Operationsmulti instanceconsolidationrelease

FromDual has the pleasure to announce the release of the new version 1.0.2 of its popular multi-instance MySQL Environment MyEnv.

You can download MyEnv from here.

In the inconceivable case that you find a bug in MyEnv please report it to our Bugtracker.

Any feedback, statements and testimonials are welcome as well! Please send them to feedback@fromdual.com.

If you have questions about MyEnv we will answer them in the MyEnv forum.

Upgrade from 1.0.x to 1.0.2 # cd /home/mysql/product # tar xf /tmp/myenv-1.0.2.tar.gz # rm -f myenv # ln -s myenv-1.0.2 myenv

Add the following line to your ~/.bash_profile:

# BEGIN MyEnv # Written by the MyEnv installMyEnv.php script. . /etc/myenv/MYENV_BASE MYENV_PWD=`pwd` cd $MYENV_BASE/bin . myenv.profile up cd $MYENV_PWD # END MyEnv Changes in MyEnv 1.0.2 MyEnv

• Missing [client] section in my.cnf should not lead to error any more (Bug #95).
• profile.template removed because it is redundant to installer information.
• up removed from myenv.profile.
• Also root should be allowed to start MySQL (Bug #99).
• Status for OEM agent implemented (oem_agent.php). To activate this feature copy it from utl/oem_agent.php to plg/showMyEnvStatus/.
• Plug-in interface for showMyEnvStatus.php implemented.
• Debug information improved.
• Empty line after environment switch removed.
• One missing error line in myenv_start_stop.php was added.
• Return code in myenv_start_stop.php is nicer now.
• Difference between my.cnf and myenv.conf should be warning and not an error.
• Error messages made more precise.
• Made it more clear that MyEnv is distributed under GPL v2.
• Deleting the actual instance with MyEnv Installer should no longer confuse MyEnv (Bug #104).
• RPM packages for CentOS 6, Fedora 18 and 19, RHEL 5 and 6 are available.

MyEnv Installer

• User experience during deleting an instance improved (Bug #96).
• Deleting a running instance is not allowed. Much more verbose information about (Bug #89).
• Instance name black list added.
• Instances should be listed when change was chosen (#93).
• Replace multi-line readline output to fixed crippled output in menu selection (Bug #103).

MyEnv Utilities

• alter_engine.pl should now work for socket and port, local and remote.
• Password is not exposed any more in alter_engine.pl.
• Query bench (query_bench.phpx) added for micro bench marks.

MySQL Backup Manager

• Automated mysql_bman tests should all pass again.

Taxonomy upgrade extras: myenvoperationMySQL Operationsmulti instanceconsolidationrelease

Taxonomy upgrade extras: myenvoperationMySQL Operationsmulti instanceconsolidation

FromDual has the pleasure to announce the release of the new version 1.0.2 of its popular multi-instance MySQL Environment MyEnv.

You can download MyEnv from here.

In the inconceivable case that you find a bug in MyEnv please report it to our Bugtracker.

Any feedback, statements and testimonials are welcome as well! Please send them to feedback@fromdual.com.

If you have questions about MyEnv we will answer them in the MyEnv forum.

Upgrade from 1.0.x to 1.0.2 # cd /home/mysql/product # tar xf /tmp/myenv-1.0.2.tar.gz # rm -f myenv # ln -s myenv-1.0.2 myenv

Add the following line to your ~/.bash_profile:

# BEGIN MyEnv # Written by the MyEnv installMyEnv.php script. . /etc/myenv/MYENV_BASE MYENV_PWD=`pwd` cd $MYENV_BASE/bin . myenv.profile up cd $MYENV_PWD # END MyEnv Changes in MyEnv 1.0.2 MyEnv

• Missing [client] section in my.cnf should not lead to error any more (Bug #95).
• profile.template removed because it is redundant to installer information.
• up removed from myenv.profile.
• Also root should be allowed to start MySQL (Bug #99).
• Status for OEM agent implemented (oem_agent.php). To activate this feature copy it from utl/oem_agent.php to plg/showMyEnvStatus/.
• Plug-in interface for showMyEnvStatus.php implemented.
• Debug information improved.
• Empty line after environment switch removed.
• One missing error line in myenv_start_stop.php was added.
• Return code in myenv_start_stop.php is nicer now.
• Difference between my.cnf and myenv.conf should be warning and not an error.
• Error messages made more precise.
• Made it more clear that MyEnv is distributed under GPL v2.
• Deleting the actual instance with MyEnv Installer should no longer confuse MyEnv (Bug #104).
• RPM packages for CentOS 6, Fedora 18 and 19, RHEL 5 and 6 are available.

MyEnv Installer

• User experience during deleting an instance improved (Bug #96).
• Deleting a running instance is not allowed. Much more verbose information about (Bug #89).
• Instance name black list added.
• Instances should be listed when change was chosen (#93).
• Replace multi-line readline output to fixed crippled output in menu selection (Bug #103).

MyEnv Utilities

• alter_engine.pl should now work for socket and port, local and remote.
• Password is not exposed any more in alter_engine.pl.
• Query bench (query_bench.phpx) added for micro bench marks.

MySQL Backup Manager

• Automated mysql_bman tests should all pass again.

FromDual sucht enthusiastische Mitarbeiter die:

• Kenntnisse über MySQL, Percona Server oder MariaDB aufweisen oder sich aneignen wollen
• mit dem Open-Source Ökosystem vertraut sind und Beiträge dazu geleistet haben
• als DBA oder DevOps wissen, wie man Datenbank-Systeme betreibt
• verstehen, was beim Betrieb von Datenbanken falsch gemacht werden kann
• gerne selbständig remote arbeiten und über IRC, Skype, Mail und Telefon zu kommunizieren gewohnt sind
• sich auf Linux Systemen gut auskennen und wohl fühlen
• gute Team-Player sind und zum Wachstum der Firma beitragen wollen
• gerne den direkten Kontakt mit Kunden haben und
• auf der Suche nach einer neuen Herausforderung sind

Stellenbeschreibung

Wir suchen deutschsprachige vollzeit MySQL Support DBA's (Sie oder Ihn), welche primär für unsere MySQL Support Dienstleistungen zuständig sind und unseren Kunden helfen, ihre MySQL Datenbanken zu betreiben (Support und remote-DBA).

Du bist fit in MySQL und:

• hast Erfahrung im Betrieb kritischer und hoch verfügbarer produktiver MySQL Datenbanken hauptsächlich auf Linux.
• Deine tägliche Arbeit ist MySQL-Replikation in allen Variationen.
• weisst, wie die meist verbreitetsten MySQL HA Setups funktionieren und wie man sie wieder effizient repariert, wenn ein Problem auftritt. (Wenn Du bereits Erfahrungen mit Galera Cluster gesammelt hast, ist das ein Vorteil!)
• kennst die gängigen Open-Source Technologien (LAMP Stack, etc.)
• kannst Bash skripten und einfache Programme in mindestens einer verbreiteten Programmier-/Skripting-Sprache (Perl, PHP, ...) erstellen.

Du wirst im direkten Kontakt mit Kunden stehen. Du hast ein gutes Gespür für deren Probleme und kannst zuhören, weisst wie antworten und findest die eigentlichen Probleme. Du wirst proaktiv handeln, bevor etwas passiert und den Kunden wieder auf den richtigen Pfad führen.
Du bist ein guter Kommunikator und ein aktiver Team Player.

Um Deine Arbeit erledigen zu können, arbeitest Du in einer europäischen Zeitzone. Deine Arbeitszeit kannst Du in bestimmten Grenzen flexibel gestalten. Wir erwarten, dass Du Deinen Beitrag zum Bereitschaftsdienst leistest. FromDual hat voraussichtlich keine Büroräumlichkeiten in Deinem Wohnort, aber ein Umzug ist nicht notwendig: Wir ermöglichen das Arbeiten von zu hause oder unterstützen bei der Suche einer geeigneten Arbeitsräumlichkeit. Gute schriftliche und mündliche Englischkenntnisse sind zwingend.

Neben Deiner Tätigkeit als Support DBA erwarten wir, dass Du Dir laufend neue Kenntnisse aneignest und Deine Fähigkeiten verbesserst sowie dazu beiträgst, unsere Monitoring-Lösung, unsere Datenbank-Steuerung und unseren weiteren Tools zu verbessern. Im weiteren würden wir es sehr schätzen, wenn Du regelmässig zur Verfassung technischer Artikel (Blog oder Zeitschriften) beiträgst und überall mit hilfst, wo Hilfe nötig ist...

Du solltest in der Lage sein, die meiste Zeit selbständig zu arbeiten, denken und zu handeln und Dir neues Wissen selbständig anzueignen (durch Google, die MySQL Dokumentation, Ausprobieren, etc.). Wenn Du mal nicht weiterkommst, werden Dir Deine Kollegen von FromDual gerne helfen.

Wenn Du jemanden brauchst, der Dir die ganze Zeit Dein Händchen hält, ist FromDual nicht die richtige Wahl.

Wer ist FromDual?

FromDual ist die führende unabhängige MySQL Beratungs- und Dienstleistungs-Firma in Europa mit ihrem Hauptsitz in der Schweiz.

Unsere Kunden befinden sich hauptsächlich in Europa und reichen vom kleinen Start-Up bis zur europäischen Top-500 Firma.

Du wirst in einer spannenden Zeit zu uns stossen. Wir sind am wachsen und brauchen die entsprechenden Leute, welche selbst und mit uns wachsen wollen. In dem Mass, wie wir uns weiter entwickeln, muss auch unser Team wachsen uns seine Fähigkeiten erweitern.

Wie geht es weiter

Wenn Du an dieser Chance interessiert bist und Du denkst, dass Du die passende Kandidatin oder der passende Kandidat bist (wir wissen, dass es niemanden gibt, der 100% auf diese Stellenbeschreibung passt!), würden wir uns freuen, von Dir zu hören.

Bitte schicke Deinen ungeschönten Lebenslauf mit Deinen Lohnvorstellungen und einer Liste Deiner Open-Source Beiträgen, Blog-Artikel, Vorträgen, Tweets etc. an jobs@fromdual.com. Wenn Du mehr über diese Stelle erfahren oder wenn Du mit mir persönlich sprechen möchtest, ruf mich bitte an unter +41 79 830 09 33 (Oli Sennhauser, CTO). Bitte nur Bewerber, KEINE Headhunter!

Nachdem wir Deinen Lebenslauf erhalten und geprüft haben, laden wir Dich ein, Deine technischen Fähigkeiten in einem kleinen MySQL-Test unter Beweis zu stellen. Wenn Du den Test bestanden hast, laden wir Dich für die finalen Interviews ein.

Dieses Stellenangebot ist offen bis 31. Januar 2014

FromDual sucht enthusiastische Mitarbeiter die:

• Kenntnisse über MySQL, Percona Server oder MariaDB aufweisen oder sich aneignen wollen
• mit dem Open-Source Ökosystem vertraut sind und Beiträge dazu geleistet haben
• als DBA oder DevOps wissen, wie man Datenbank-Systeme betreibt
• verstehen, was beim Betrieb von Datenbanken falsch gemacht werden kann
• gerne selbständig remote arbeiten und über IRC, Skype, Mail und Telefon zu kommunizieren gewohnt sind
• sich auf Linux Systemen gut auskennen und wohl fühlen
• gute Team-Player sind und zum Wachstum der Firma beitragen wollen
• gerne den direkten Kontakt mit Kunden haben und
• auf der Suche nach einer neuen Herausforderung sind

Stellenbeschreibung

Wir suchen deutschsprachige vollzeit MySQL Support DBA's (Sie oder Ihn), welche primär für unsere MySQL Support Dienstleistungen zuständig sind und unseren Kunden helfen, ihre MySQL Datenbanken zu betreiben (Support und remote-DBA).

Du bist fit in MySQL und:

• hast Erfahrung im Betrieb kritischer und hoch verfügbarer produktiver MySQL Datenbanken hauptsächlich auf Linux.
• Deine tägliche Arbeit ist MySQL-Replikation in allen Variationen.
• weisst, wie die meist verbreitetsten MySQL HA Setups funktionieren und wie man sie wieder effizient repariert, wenn ein Problem auftritt. (Wenn Du bereits Erfahrungen mit Galera Cluster gesammelt hast, ist das ein Vorteil!)
• kennst die gängigen Open-Source Technologien (LAMP Stack, etc.)
• kannst Bash skripten und einfache Programme in mindestens einer verbreiteten Programmier-/Skripting-Sprache (Perl, PHP, ...) erstellen.

Du wirst im direkten Kontakt mit Kunden stehen. Du hast ein gutes Gespür für deren Probleme und kannst zuhören, weisst wie antworten und findest die eigentlichen Probleme. Du wirst proaktiv handeln, bevor etwas passiert und den Kunden wieder auf den richtigen Pfad führen.
Du bist ein guter Kommunikator und ein aktiver Team Player.

Um Deine Arbeit erledigen zu können, arbeitest Du in einer europäischen Zeitzone. Deine Arbeitszeit kannst Du in bestimmten Grenzen flexibel gestalten. Wir erwarten, dass Du Deinen Beitrag zum Bereitschaftsdienst leistest. FromDual ist eine vollständig virtuelle Firma. Ein Umzug ist daher nicht notwendig (Home-Office). Gute schriftliche und mündliche Englischkenntnisse sind zwingend.

Neben Deiner Tätigkeit als Support DBA erwarten wir, dass Du Dir laufend neue Kenntnisse aneignest und Deine Fähigkeiten verbesserst sowie dazu beiträgst, unsere Monitoring-Lösung, unsere Datenbank-Steuerung und unseren weiteren Tools zu verbessern. Im weiteren würden wir es sehr schätzen, wenn Du regelmässig zur Verfassung technischer Artikel (Blog oder Zeitschriften) beiträgst und überall mit hilfst, wo Hilfe nötig ist...

Du solltest in der Lage sein, die meiste Zeit selbständig zu arbeiten, denken und zu handeln und Dir neues Wissen selbständig anzueignen (durch Google, die MySQL Dokumentation, Ausprobieren, etc.). Wenn Du mal nicht weiterkommst, werden Dir Deine Kollegen von FromDual gerne helfen.

Wenn Du jemanden brauchst, der Dir die ganze Zeit Dein Händchen hält, ist FromDual nicht die richtige Wahl.

Wer ist FromDual?

FromDual ist die führende unabhängige MySQL Beratungs- und Dienstleistungs-Firma in Europa mit ihrem Hauptsitz in der Schweiz.

Unsere Kunden befinden sich hauptsächlich in Europa und reichen vom kleinen Start-Up bis zur europäischen Top-500 Firma.

Du wirst in einer spannenden Zeit zu uns stossen. Wir sind am wachsen und brauchen die entsprechenden Leute, welche selbst und mit uns wachsen wollen. In dem Mass, wie wir uns weiter entwickeln, muss auch unser Team wachsen uns seine Fähigkeiten erweitern.

Wie geht es weiter

Wenn Du an dieser Chance interessiert bist und Du denkst, dass Du die passende Kandidatin oder der passende Kandidat bist (wir wissen, dass es niemanden gibt, der 100% auf diese Stellenbeschreibung passt!), würden wir uns freuen, von Dir zu hören.

Bitte schicke Deinen ungeschönten Lebenslauf mit Deinen Lohnvorstellungen und einer Liste Deiner Open-Source Beiträgen, Blog-Artikel, Vorträgen, Tweets etc. an jobs@fromdual.com. Wenn Du mehr über diese Stelle erfahren oder wenn Du mit mir persönlich sprechen möchtest, ruf mich bitte an unter +41 79 830 09 33 (Oli Sennhauser, CTO). Bitte nur Bewerber, KEINE Headhunter!

Nachdem wir Deinen Lebenslauf erhalten und geprüft haben, laden wir Dich ein, Deine technischen Fähigkeiten in einem kleinen MySQL-Test unter Beweis zu stellen. Wenn Du den Test bestanden hast, laden wir Dich für die finalen Interviews ein.

Dieses Stellenangebot ist offen bis 31. Januar 2014

Table of Content

• Introduction
• Prerequisites
• What is MyEnv?
• MySQL Workbench configuration.
  • Add MySQL connections to MySQL Workbench.
  • Start/Stop instance configurations.

Introduction

MySQL Workbench is a very good and free GUI tool provided by Oracle to manage MySQL administration and development tasks. Opening many MySQL connections (same or different instances, remote or local MySQL servers) at the same time is one of its main features. While it's working fine to perform SQL statements on the different connections opened for multiple instances, but some people are asking if it is available as well to start and stop multiple MySQL instances using MySQL Workbench? if yes, how to configure it to perform such task? and also does that make any conflict with MyEnv tool - if it's installed - or not?
Yes, MySQL Workbench could be configured to start and stop multiple MySQL instances (local or remote) and it does not make any conflict with MyEnv tool.

In this article, I will describe how to configure MySQL Workbench to start and stop multiple MySQL instances and getting benefits from MyEnv scripts in this purpose.

Prerequisites

System information and installed packages:

• Operating System: Ubuntu 12.04 (64 bit) .
• MySQL Server: Any mysql version (I used MySQL 5.5 tarballs).
• Number of MySQL Instances: Two instances are installed (mysql1 & mysql2).
• MySQL Workbench: Version 6.0 .
• MyEnv: Version 1.0.1.

What is MyEnv?

MyEnv is a set of scripts to run comfortably multiple MySQL, Percona Server or MariaDB database instances on the same server. You can even run multiple database instances with different binary versions. If you have MySQL multiple instance setups, you really should try out MyEnv.

I will not talk more about MyEnv features and its benefits rather, I'd like to mention that if you're using MyEnv and want to use MySQL Workbench at the same time, you will not face any conflict between them both and you can manage your MySQL instances by either MyEnv or MySQL Workbench. More over, you can use MyEnv scripts to configure MySQL Workbench starting/stopping multiple instances in an easy way!

For more information about MyEnv tool , you can check it out on our website myenv.

MySQL Workbench configuration
Add MySQL connections to MySQL Workbench

• Choose a connection name for the 1st instance "mysql1" and specify the connection string:
  
  

  If you didn't adjust the "Configure Server Management" in this step - at the left bottom of the previous screen - you can open MySQL connections and perform SQL queries normally to this instance but you can neither edit the instance configuration parameters nor start/stop it.
  BTW, you can adjust it at anytime later and that what I did already in this example.

• Add another connection for the 2nd instance "mysql2" the same like "mysql1".

Start/Stop instance configurations

To configure MySQL Workbench to start/stop instance, we need to have relevant start and stop commands because it just execute them as they would be execute in the system shell. In this case, we may get benefit of MyEnv scripts for that purpose using the following command:

$MYENV_BASE/bin/database.php $MYENV_DATABASE start|stop
Where $MYENV_BASE is the MyEnv basedir ("/opt/myenv" in this ex.) and $MYENV_DATABASE is the instance name in MyEnv (mysqld1 & mysqld2 for mysql1 & mysql2 respectively in this ex.)

Now, we can use the following window to modify System type,Configuration file path, start , stop and status commands to match each instance configurations:

Now MySQL Workbench should be able to start and stop the configured MySQL instances.

Notes:

• MyEnv doesn't allow any user to start a mysql instance except mysql user (even if it's the root user), so that mysql OS user should be used to execute those commands and you might need to assign it SUDO permissions.
• Start/Stop Server button in MySQL Workbench depends on the output of the status command used ("cat /opt/mysql1/data/*.pid 2>/dev/null" for checking mysql1 instance status), and the button label will be changed to execute the appropriate command accordingly (for ex. if the instance is not running, the label should be changed to "Start Server" and the start command will be executed if the button clicked and vise verse), so you should make sure that this command is returning the expected results, otherwise, Workbench wont be able to manage the instance.
• It doesn't matter how MySQL was installed (RPM, tarballs or from source), it's the same concept, you just need to provide MyEnv start and stop commands along with the status command and then MySQL Workbench will work.
• If MyEnv is not installed, you can also configure MySQL Workbench to start/stop multiple instances by providing normal start|stop instance commands in the "Manage Server Connections" window but those need to be prepared first.

Taxonomy upgrade extras: MyEnv

Table of Content

• Introduction
• Prerequisites
• What is MyEnv?
• MySQL Workbench configuration.
  • Add MySQL connections to MySQL Workbench.
  • Start/Stop instance configurations.

Introduction

MySQL Workbench is a very good and free GUI tool provided by Oracle to manage MySQL administration and development tasks. Opening many MySQL connections (same or different instances, remote or local MySQL servers) at the same time is one of its main features. While it's working fine to perform SQL statements on the different connections opened for multiple instances, but some people are asking if it is available as well to start and stop multiple MySQL instances using MySQL Workbench? if yes, how to configure it to perform such task? and also does that make any conflict with MyEnv tool - if it's installed - or not?
Yes, MySQL Workbench could be configured to start and stop multiple MySQL instances (local or remote) and it does not make any conflict with MyEnv tool.

In this article, I will describe how to configure MySQL Workbench to start and stop multiple MySQL instances and getting benefits from MyEnv scripts in this purpose.

Prerequisites

System information and installed packages:

• Operating System: Ubuntu 12.04 (64 bit) .
• MySQL Server: Any mysql version (I used MySQL 5.5 tarballs).
• Number of MySQL Instances: Two instances are installed (mysql1 & mysql2).
• MySQL Workbench: Version 6.0 .
• MyEnv: Version 1.0.1.

What is MyEnv?

MyEnv is a set of scripts to run comfortably multiple MySQL, Percona Server or MariaDB database instances on the same server. You can even run multiple database instances with different binary versions. If you have MySQL multiple instance setups, you really should try out MyEnv.

I will not talk more about MyEnv features and its benefits rather, I'd like to mention that if you're using MyEnv and want to use MySQL Workbench at the same time, you will not face any conflict between them both and you can manage your MySQL instances by either MyEnv or MySQL Workbench. More over, you can use MyEnv scripts to configure MySQL Workbench starting/stopping multiple instances in an easy way!

For more information about MyEnv tool , you can check it out on our website myenv.

MySQL Workbench configuration
Add MySQL connections to MySQL Workbench

• Choose a connection name for the 1st instance "mysql1" and specify the connection string:
  
  

  If you didn't adjust the "Configure Server Management" in this step - at the left bottom of the previous screen - you can open MySQL connections and perform SQL queries normally to this instance but you can neither edit the instance configuration parameters nor start/stop it.
  BTW, you can adjust it at anytime later and that what I did already in this example.

• Add another connection for the 2nd instance "mysql2" the same like "mysql1".

Start/Stop instance configurations

To configure MySQL Workbench to start/stop instance, we need to have relevant start and stop commands because it just execute them as they would be execute in the system shell. In this case, we may get benefit of MyEnv scripts for that purpose using the following command:

$MYENV_BASE/bin/database.php $MYENV_DATABASE start|stop
Where $MYENV_BASE is the MyEnv basedir ("/opt/myenv" in this ex.) and $MYENV_DATABASE is the instance name in MyEnv (mysqld1 & mysqld2 for mysql1 & mysql2 respectively in this ex.)

Now, we can use the following window to modify System type,Configuration file path, start , stop and status commands to match each instance configurations:

Now MySQL Workbench should be able to start and stop the configured MySQL instances.

Notes:

• MyEnv doesn't allow any user to start a mysql instance except mysql user (even if it's the root user), so that mysql OS user should be used to execute those commands and you might need to assign it SUDO permissions.
• Start/Stop Server button in MySQL Workbench depends on the output of the status command used ("cat /opt/mysql1/data/*.pid 2>/dev/null" for checking mysql1 instance status), and the button label will be changed to execute the appropriate command accordingly (for ex. if the instance is not running, the label should be changed to "Start Server" and the start command will be executed if the button clicked and vise verse), so you should make sure that this command is returning the expected results, otherwise, Workbench wont be able to manage the instance.
• It doesn't matter how MySQL was installed (RPM, tarballs or from source), it's the same concept, you just need to provide MyEnv start and stop commands along with the status command and then MySQL Workbench will work.
• If MyEnv is not installed, you can also configure MySQL Workbench to start/stop multiple instances by providing normal start|stop instance commands in the "Manage Server Connections" window but those need to be prepared first.

Taxonomy upgrade extras: MyEnv

Table of Content

• Introduction
• Prerequisites
• What is MyEnv?
• MySQL Workbench configuration.
  • Add MySQL connections to MySQL Workbench.
  • Start/Stop instance configurations.

Introduction

MySQL Workbench is a very good and free GUI tool provided by Oracle to manage MySQL administration and development tasks. Opening many MySQL connections (same or different instances, remote or local MySQL servers) at the same time is one of its main features. While it's working fine to perform SQL statements on the different connections opened for multiple instances, but some people are asking if it is available as well to start and stop multiple MySQL instances using MySQL Workbench? if yes, how to configure it to perform such task? and also does that make any conflict with MyEnv tool - if it's installed - or not?
Yes, MySQL Workbench could be configured to start and stop multiple MySQL instances (local or remote) and it does not make any conflict with MyEnv tool.

In this article, I will describe how to configure MySQL Workbench to start and stop multiple MySQL instances and getting benefits from MyEnv scripts in this purpose.

Prerequisites

System information and installed packages:

• Operating System: Ubuntu 12.04 (64 bit) .
• MySQL Server: Any mysql version (I used MySQL 5.5 tarballs).
• Number of MySQL Instances: Two instances are installed (mysql1 & mysql2).
• MySQL Workbench: Version 6.0 .
• MyEnv: Version 1.0.1.

What is MyEnv?

MyEnv is a set of scripts to run comfortably multiple MySQL, Percona Server or MariaDB database instances on the same server. You can even run multiple database instances with different binary versions. If you have MySQL multiple instance setups, you really should try out MyEnv.

I will not talk more about MyEnv features and its benefits rather, I'd like to mention that if you're using MyEnv and want to use MySQL Workbench at the same time, you will not face any conflict between them both and you can manage your MySQL instances by either MyEnv or MySQL Workbench. More over, you can use MyEnv scripts to configure MySQL Workbench starting/stopping multiple instances in an easy way!

For more information about MyEnv tool , you can check it out on our website myenv.

MySQL Workbench configuration
Add MySQL connections to MySQL Workbench

• Choose a connection name for the 1st instance "mysql1" and specify the connection string:
  
  

  If you didn't adjust the "Configure Server Management" in this step - at the left bottom of the previous screen - you can open MySQL connections and perform SQL queries normally to this instance but you can neither edit the instance configuration parameters nor start/stop it.
  BTW, you can adjust it at anytime later and that what I did already in this example.

• Add another connection for the 2nd instance "mysql2" the same like "mysql1".

Start/Stop instance configurations

To configure MySQL Workbench to start/stop instance, we need to have relevant start and stop commands because it just execute them as they would be execute in the system shell. In this case, we may get benefit of MyEnv scripts for that purpose using the following command:

$MYENV_BASE/bin/database.php $MYENV_DATABASE start|stop
Where $MYENV_BASE is the MyEnv basedir ("/opt/myenv" in this ex.) and $MYENV_DATABASE is the instance name in MyEnv (mysqld1 & mysqld2 for mysql1 & mysql2 respectively in this ex.)

Now, we can use the following window to modify System type,Configuration file path, start , stop and status commands to match each instance configurations:

Now MySQL Workbench should be able to start and stop the configured MySQL instances.

Notes:

• MyEnv doesn't allow any user to start a mysql instance except mysql user (even if it's the root user), so that mysql OS user should be used to execute those commands and you might need to assign it SUDO permissions.
• Start/Stop Server button in MySQL Workbench depends on the output of the status command used ("cat /opt/mysql1/data/*.pid 2>/dev/null" for checking mysql1 instance status), and the button label will be changed to execute the appropriate command accordingly (for ex. if the instance is not running, the label should be changed to "Start Server" and the start command will be executed if the button clicked and vise verse), so you should make sure that this command is returning the expected results, otherwise, Workbench wont be able to manage the instance.
• It doesn't matter how MySQL was installed (RPM, tarballs or from source), it's the same concept, you just need to provide MyEnv start and stop commands along with the status command and then MySQL Workbench will work.
• If MyEnv is not installed, you can also configure MySQL Workbench to start/stop multiple instances by providing normal start|stop instance commands in the "Manage Server Connections" window but those need to be prepared first.

Sehr geehrte Damen und Herren,

Am Donnerstag, 5. Dezember kommt Virident nach Zürich um ihre Enterprise Flash Speicher für den Datenbank-Einsatz vorzustellen.

Ryan Taylor und Mark Lucas werden diese fortschrittliche Technologie vorstellen und aufzeigen, wie führende Unternehmen wie LinkedIn Virident Produkte wirksam einsetzten um ihre Datenbankanwendungen zu beschleunigen. Danach zeigt Oli Sennhauser (CTO von FromDual) auf, wo und wie Flash Speicher mit MySQL (und anderen Datenbanken) am besten zum Einsatz gebracht wird und wie er die Datenbanken beschleunigt.

Nehmen sie teil an der Frage- und Antwort-Runde sowie dem Erfahrungsaustausch über Flash Speicher im allgemeinen und dem Datenbankbetrieb im speziellen.

Die Runde ist kostenlos und erfolgt vorwiegend in englischer Sprache. Virident wird die Produkte mitbringen, damit sich die Teilnehmer ein Bild davon machen können. Sollten sie diese fortschrittliche Technologie selber bei sich testen wollen, unterstützt Virident sie dabei kostenlos und ohne weitere Verpflichtungen. Die perfekte Art selber praktische und unabhängige Benchmarks mit ihren Daten und Anwendungen durchzuführen.

Der Anlass findet am Donnerstag, 5. Dezember von 15:00 bis 17:30 im Crowne Plaza Hotel an der Badenerstrasse 420 in 8048 Zürich statt.

Bitte kündigen sie uns ihre Teilnahme vorher per Mail an, damit wir ihnen einen Platz reservieren und die benötigten Ressourcen zur Verfügung stellen können.

Mit freundlichen Grüssen,
Ihr FromDual Team

Sehr geehrte Damen und Herren,

Am Donnerstag, 5. Dezember kommt Virident nach Zürich um ihre Enterprise Flash Speicher für den Datenbank-Einsatz vorzustellen.

Ryan Taylor und Mark Lucas werden diese fortschrittliche Technologie vorstellen und aufzeigen, wie führende Unternehmen wie LinkedIn Virident Produkte wirksam einsetzten um ihre Datenbankanwendungen zu beschleunigen. Danach zeigt Oli Sennhauser (CTO von FromDual) auf, wo und wie Flash Speicher mit MySQL (und anderen Datenbanken) am besten zum Einsatz gebracht wird und wie er die Datenbanken beschleunigt.

Nehmen sie teil an der Frage- und Antwort-Runde sowie dem Erfahrungsaustausch über Flash Speicher im allgemeinen und dem Datenbankbetrieb im speziellen.

Die Runde ist kostenlos und erfolgt vorwiegend in englischer Sprache. Virident wird die Produkte mitbringen, damit sich die Teilnehmer ein Bild davon machen können. Sollten sie diese fortschrittliche Technologie selber bei sich testen wollen, unterstützt Virident sie dabei kostenlos und ohne weitere Verpflichtungen. Die perfekte Art selber praktische und unabhängige Benchmarks mit ihren Daten und Anwendungen durchzuführen.

Der Anlass findet am Donnerstag, 5. Dezember von 15:00 bis 17:30 im Crowne Plaza Hotel an der Badenerstrasse 420 in 8048 Zürich statt.

Bitte kündigen sie uns ihre Teilnahme vorher per Mail an, damit wir ihnen einen Platz reservieren und die benötigten Ressourcen zur Verfügung stellen können.

Mit freundlichen Grüssen,
Ihr FromDual Team

Sehr geehrte Damen und Herren,

Am Donnerstag, 5. Dezember kommt Virident nach Zürich um ihre Enterprise Flash Speicher für den Datenbank-Einsatz vorzustellen.

Ryan Taylor und Mark Lucas werden diese fortschrittliche Technologie vorstellen und aufzeigen, wie führende Unternehmen wie LinkedIn Virident Produkte wirksam einsetzten um ihre Datenbankanwendungen zu beschleunigen. Danach zeigt Oli Sennhauser (CTO von FromDual) auf, wo und wie Flash Speicher mit MySQL (und anderen Datenbanken) am besten zum Einsatz gebracht wird und wie er die Datenbanken beschleunigt.

Nehmen sie teil an der Frage- und Antwort-Runde sowie dem Erfahrungsaustausch über Flash Speicher im allgemeinen und dem Datenbankbetrieb im speziellen.

Die Runde ist kostenlos und erfolgt vorwiegend in englischer Sprache. Virident wird die Produkte mitbringen, damit sich die Teilnehmer ein Bild davon machen können. Sollten sie diese fortschrittliche Technologie selber bei sich testen wollen, unterstützt Virident sie dabei kostenlos und ohne weitere Verpflichtungen. Die perfekte Art selber praktische und unabhängige Benchmarks mit ihren Daten und Anwendungen durchzuführen.

Der Anlass findet am Donnerstag, 5. Dezember von 15:00 bis 17:30 im Crowne Plaza Hotel an der Badenerstrasse 420 in 8048 Zürich statt.

Bitte kündigen sie uns ihre Teilnahme vorher per Mail an, damit wir ihnen einen Platz reservieren und die benötigten Ressourcen zur Verfügung stellen können.

Mit freundlichen Grüssen,
Ihr FromDual Team

Great News: Galera Cluster v3.1 GA for MySQL 5.6 was released at Percona Live London (PLUK) 2013. The information is still a bit hidden...

You can find it here:

• The Plug-in: https://launchpad.net/galera/3.x/25.3.1
• The MySQL: https://launchpad.net/codership-mysql/5.6/5.6.14-25.1

Or directly on our download page.

Careful: Online-Upgrade from 5.5 to 5.6 will not work yet. We have to find a work-around...