Wednesday, April 13, 2011

MySQL Workbench Utilities

One of the many new things that is being introduced this week are some great new external tools for managing MySQL servers. These are available in MySQL Workbench under the name MySQL Workbench Utilities.

It is a package of easy-to-use utilities for maintenance and administration of MySQL servers. These utilities encapsulate a set of primitive commands bundling them so that you can perform macro operations with a single command.

Some of the key features of MySQL Workbench Utilities are:
  • Plugin for MySQL Workbench 5.2.31
  • Available under the GPLv2 license
  • Written in Python
  • Easily to extend using the supplied library


How Does It Work?
There are two ways to access the utilities from within the MySQL Workbench.

You can click on the drop down arrow icon to the right of the MySQL Workbench main window. This will display a list of the plugins available. You can scroll through the screens and find the MySQL Utilities icon. The image below shows what the window looks like.



Once you hover on the MySQL Utilities icon, you will see an Action button appear. Click Action then Start Plugin to launch the MySQL Utilities shell in a new window. The image below shows what the window would look like.



You can launch any of the utilities listed by typing the name of the command. To find out what options are available, use the --help option.

Note: you can also add the MySQL Utilities icon to your home screen. Highlight Add to Home Screen and then choose a position from the menu.

You can also launch the MySQL Utilities command window by clicking on the Plugins menu item and selecting Start Shell for MySQL Utilities.

What Utilities are Available?
The MySQL Workbench and MySQL Workbench Utilities developers are adding new features and utilities with every release. If you don’t see a utility you want, check back with each release of Workbench or send the developers an email and let them know what you want!

You should try the --help option for each tool to see what options it supports. Some utilities have lots of options for controlling the operation (for example the mysqldbexport can produce one of several formats with object definitions, data, or both).

There are several options that are common to the utilities available (for instance --version, --help, --verbose) but the one that is most important is the server specification option used to connect to a specific server. This manifests as --server, --source, --destination, or --server1, etc. and all require the same \
format as follows:

--server=user_name:password@hostname:port_num:socket_file.

The parameter includes the user name followed by the user’s password (if available) separated by a colon (colon is omitted if no password) followed by the @ symbol and the host machine name. Optionally, you can provide the port number and the socket file each preceded by a colon. That sounds like a lot of crazy typin\
g but it is really simple. The following are some examples using this format.

--server=root@localhost:3306
--server=joe:pass@192.168.1.101
--server=dolly:sassyshoes@localhost:3310:/tmp/mysql.sock

The following list describes the utilities available as well as some examples of use. For more details, please see the manuals for each utility.

mysqldbcopy - Permits a database administrator to copy a database from one server either to another server as the same name or a different name or to the same server as the same or as a different name.

Example 1: Copy  a database  named  ‘util_test’ to a new name ‘util_test_copy’ on the same server.

mysqldbcopy util_test:util_test_copy
  --source=root:pass@host1:3306
  --destination=root:pass@host1:3306

Example 2: Copy  a database  named  ‘util_test’ to another server.

mysqldbcopy util_test:util_test
  --source=root:pass@host1:3306
  --destination=root:pwd@host2:33010

mysqldbexport - Permits a database administrator to export the metadata (object definitions, hence definitions) or data or both from one or more databases. By default, the utility will export only definitions.

Example 1: Export the definitions of the database ‘dev’ from a MySQL server  on  localhost via port 3306 producing CREATE statements.

mysqldbexport --skip=GRANTS
  --server=root:pass@localhost
  --export=DEFINITIONS util_test

Example 2: Export  the  data of the database ‘util_test’ producing bulk insert statements.

mysqldbexport --export=DATA
  --bulk-insert util_test
  --server=root:pass@localhost

mysqldbimport - Permits a database administrator to import the metadata (objects) or data for one or more databases from one or more files in either SQL or a text format such as CSV, TAB, GRID, or VERTICAL.

Example 1: Import the metadata of the database ‘util_test’ to server1  on  port 3306 using a file in CSV format.

mysqldbimport --import=definitions
  --server=root@localhost --format=csv
  data.csv

Example 2: Import  both  the  data  and  definitions  of  the  database ‘util_test’  to  server1  on port 3306 producing bulk insert statements from a file that contains SQL statements.

mysqldbimport data.sql --import=both
  --bulk-insert --format=sql
  --server=root@localhost

mysqldiff -  Reads the definitions of objects and compares them using a diff-like method to determine if two objects are the same based on the definition of the object.

Example 1: Find the differences among objects in database employees on one server and emp1 on the same server.

mysqldiff --server1=root@localhost
  employees:emp1

Example 2: Find differences between the salaries table on one server and the same table on another server.

mysqldiff --server1=root@localhost
  --server2=root@host2:3306
  employees.salaries:emp1.salaries
  --differ

mysqldiskusage - Permits a database administrator to see the disk space usage for one or more databases in either CSV, TAB, GRID, or VERTICAL text formats. The utility will also allow the user to examine the disk usage for the binary logs, slow, error, and general log; and InnoDB tablespace usage.

mysqldiskusage - Permits a database administrator to see the disk space usage for one or more databases in either CSV, TAB, GRID, or VERTICAL text formats. The utility will also allow the user to examine the disk usage for the binary logs, slow, error, and general log; and InnoDB tablespace usage.

Example 1: Show only the disk space usage for the employees and test databases in grid format.

mysqldiskusage --server=root@localhost
  employees test

Example 2: Show all disk usage for the server in CSV format.

mysqldiskusage --server=root@localhost
  --format=csv -a

mysqlindexcheck - Eeads the indexes for one or more tables and identifies duplicate and potentially redundant indexes.

Example 1: Scan all of the tables in the employees database to see the possible redundant and duplicate indexes as well as the DROP statements for the indexes.

mysqlindexcheck --server=root@localhost
  --show-drops employees

Example 2: Scan all of the tables in the employees database and display the indexes. Display the output in a tabular format.

mysqlindexcheck --server=root@localhost
  --show-indexes --format=TAB employees

mysqlmetagrep - Searches for objects matching a given pattern and shows a table of the objects that match the pattern `’t\_’.

mysqlmetagrep --pattern=“t_”
  --server=mats@localhost

Example 2: Find all objects that contain ‘t2’ in the name or the body (for routines, triggers, and events).

mysqlmetagrep -b --pattern=“%t2%”
  --server=mats@localhost:3306

mysqlprocgrep - Scans the process lists for processes that match the search criteria specified and will either print the result (the default) or execute certain actions on it.

Example 1: Kill all connections created by user “mats” that are younger than 1 minute.

mysqlprocgrep --server=root@localhost
  --match-user=mats --age=1m
  --kill-query

Example 2: Kill all connections with queries that have been idle for more than 1 hour.

mysqlprocgrep --server=root@localhost
  --match-command=sleep --age=1h
  --kill

mysqlreplicate - Permits an administrator to start replication among two servers. The user provides login information to the slave and provides connection information for connecting to the master.

Example 1: Setup replication between a MySQL instance on two different hosts using the default settings.

mysqlreplicate --rpl-user=rpl:rpl
  --master=root@localhost:3306
  --slave=root@localhost:3307

Example 2: Ensure the replication between the master and slave is successful if and only if the InnoDB storage engines are the same and both servers have the same storage engines with the same default specified.

mysqlreplicate --pedantic
  --master=root@localhost:3306
  --slave=root@localhost:3307
  --rpl-user=rpl:rpl -vv

mysqlserverclone - Permits an administrator to start a new instance of a running server.

Example 1: Create a new instance of a running server.

mysqlserverclone --new-port=3310
  --server=root:pass@localhost
  --new-data=/source/test123

Example 2: Create a new instance of a running server set the root password and turn binary logging on.

mysqlserverclone --new-port=3310
  --server=root:pass@localhost
  --new-data=/source/test123
  --root-password=pass
  --mysqld=--log-bin=mysql-bin

mysqluserclone - Permits a database administrator to use an existing user account on one server as a template and clone a MySQL user such that one or more new user accounts are created on another (or the same) server with the same privileges as the original user.

Example 1: Clone ‘joe’ as ‘sam’ and ‘sally’ with passwords and logging in as root on the local machine.

mysqluserclone --source=root@localhost
  --destination=root@localhost
  joe@localhost sam:secret1@localhost
  sally:secret2@localhost

Example 2: Show all of the users on the localhost server in the most verbose output in CSV format.

mysqluserclone --source=root@localhost
  --list --format=CSV -vvv

mut - Designed to execute predefined tests to test the MySQL Utilities.

Example 1: Run all tests.

mut --server=root@localhost

Example 2: Run all tests that start with ‘clone_user’ and set the width of the display to 70 characters.

mut --server=root@localhost
  --do-tests=clone_user –width=70

How Can I Get It?
You can download MySQL Workbench from:


You can also download the latest development source code tree for the MySQL Workbench Utilities from:

https://launchpad.net/mysql-utilities

Monday, April 11, 2011

MySQL Replication & Backup at Collaborate 11

The MySQL talks at Collaborate 11 start in just a few hours. The MySQL Replication and Backup team will make the following presentations:
  • At 11 April 11:45am, Andrei will present "Boosting MySQL Replication Performance Through Multi-Threaded Slave" in which he shows the ongoing development of the multi-threaded slave and how you can try it out for yourself.
  • At 11 April 2:30pm, I will present "MySQL Replication" and go through an overview of all the new features that has been developed for MySQL Replication. It is a long list.
  • At 12 April 3:15pm, Luis do an "Introduction to MySQL Replication" for anyone new to MySQL Replication or who wants a refreshed mind on how it works.
  • At 13 April 8:00am,  Mats presents "Sharding Techniques for MySQL" to show how you can do sharding with MySQL.
  • At 13 April 10:30am, Sanjay talks about "MySQL Enterprise Backup" and the new features we have developed for doing online backups.
  • At 14 April 09:45am, Chuck gives an "Introduction to MySQL in the Cloud" that describes how easy it is to use MySQL in a cloud.
The best way I've found to find all the MySQL talks, is to surf to http://collaborate11.ioug.org/Education/ScheduleBuilder/tabid/79/Default.aspx and enter "MySQL" as a keyword.

Also, Sheeri's blog posts contains a very good description of many of the MySQL talks:
Have a great conference!

Thursday, November 18, 2010

What information do you want in the binlog?

The MySQL task WL#4033 Informational Events includes adding information about the original query for row-based replication. This will make it easier to debug failures and user mistakes. It also makes it easier for us to add other information to the binary log. Is there some information missing that you think we should add to the binary log? Please feel free to comment on this blog entry or send me an email at firstname.lastname@oracle.com.

Tuesday, September 21, 2010

MySQL 5.5 Replication Features (MySQL Sunday)

There were several requests for copies of the replication presentation at MySQL Sunday at Oracle Open World. It will be published by the conference, but for now you can download it from www.larsthalmann.com.

There were also questions about the high availability book. It is called MySQL High Availability and was written by Chuck, Mats and me.

Tuesday, April 13, 2010

Replication features in MySQL 5.5.3

We are happy to announce the new and exciting replication features in the MySQL 5.5.3 development release.

If you are at the MySQL User Conference, you are most welcome to join the "New Replication Features" talk at 2pm today where these will be presented in more detail.
  • Semi-sync replication plugin - you can now have improved resilience of the overall replication by having a master server to wait for the slave server to collect and persist events in the relay log on a per transaction basis. As a consequence, by the time the user commits a transaction there is a guarantee that the events are already written to one or more slaves relay logs. This feature is provided as a plugin and using it is as easy as installing the plugin and enabling it.
  • Slave fsync tuning - you can now fine tune relay logs and {master|relay-log}.info fsyncs operations so that corruption is much less likely on slave crashes. Three new parameters allow you to choose how often IO and SQL threads will issue file sync. You can tweak the options to your specific needs and set them on server startup.
  • Relay log corruption recovery - you can now automatically recover corrupted slave relay logs. When this recovery mechanism is active, it will, on slave startup, search for corrupted relay logs and if corruption is found it discards them and contacts the master so that these are re-transferred. This feature, together with the new fsync options, increases slave resilience to crash faults.
  • Replication Heartbeat - MySQL slaves will now request from the master that it sends a heartbeat (event) periodically. This is done when the slave connects to the master and the heartbeat period is configurable by the user. You can now avoid the spurious relay log rotation when the master is idle and have a more precise failure detection mechanism.
  • Show Relay Logs - you can now show relay log contents, as you would do for the binlogs, by issuing 'SHOW RELAYLOG EVENTS'. This may be used for comparing the events on the master binlog against the ones in the slave relay log. In a chained replication topology, the show commands provide the ability to painlessly inspect the binary and relay logs in the servers that act both as master and slave. Additionally, it may also be used to diagnose relay log corruption.
  • Per master server event filtering - you can now instruct a MySQL slave to discard events from a specific master. The 'CHANGE MASTER' has been enriched with a new 'IGNORE_SERVER_IDS = ...' clause that allows you to configure which events should be discarded. This feature is useful in circular replication topologies. In such scenarios, a server originating an event is also responsible for removing it from the chain. However, if it is removed from the chain, its events may loop forever. With this new feature, you can instruct the replacing server to remove the old server events.
  • Slave Type Conversions - unlike statement-based replication, when using row-based replication replication between columns with different types was limited. Starting from 5.5, type promotion and demotion is now supported in row-based replication. For instance, one can now replicate seamlessly from a TINYINT column on the master to an INT column on the slave, from a CHAR(10) column to a VARCHAR(20) column, or even from a TEXT column to a VARCHAR(20) column.
  • Individual Log Flushing - the user can now selectively flush server logs when using 'FLUSH LOGS'. Given that this command has a tight connection with binary and relay log maintenance, this means that every time the user wanted to flush such logs the other server logs would flush as well. Starting from 5.5, the user can now specify which individual log to flush by providing the log type as an argument to the 'FLUSH LOGS' command.
  • Writing Non-Transactional events Directly To The Binary Log - starting from 5.5, it is safe to mix non-transactional and transactional statements in the same transaction. In row and mixed format the non-transactional statement is immediately logged instead of waiting until commit time.
To try out these features, you can download MySQL 5.5.3 from:

As always, we appreciate the community feedback. Please feel free to drop some comments or contact us.

Tuesday, December 22, 2009

How to contribute with Replication and Backup code

The MySQL Replication and Backup team is working with several community developers.

MySQL does a milestone release (roughly) every six months. To get patches included into a milestone release, it needs to be ready before the deadline for that milestone. All milestone releases are published, but not all will become GA-classified.

The below describes the process on how to get a contributed Replication or Backup patch included into a milestone release.
  1. Get acceptance of the idea. Each accepted patch needs to be thoroughly tested (by multiple teams in different ways) and we need to ensure that we can maintain it for many years. Due to this resource requirement, we can only accept a few patches per year (this number is increasing though, which is great). When your idea is accepted, you get an assigned "coach developer" that will help your patch through the procedure to get it included into a release.
  2. Get acceptance of patch. This includes multiple parts:
    • contributor agreement must be signed,
    • design must be accepted,
    • tests must be accepted, and
    • code must be accepted.
  3. Patch gets pushed into a team repository. The Replication and Backup team push the patch into the team repository. Some more testing is done. If there are problems with the patch, it can possibly be removed from the tree.
  4. Before the deadline for a milestone, the team tree gets merged into the release tree for that milestone. Release testing is done by the System QA and Server QA teams. If there are problems with the patch, it can possibly be removed from the tree.
  5. The milestone release is built from the milestone repository and is published on www.mysql.com. Some milestone releases will be marked as GA releases.
Before step 2 is completed, it is hard to know for which release it can be included into.

More information about how to contribute is available here:
http://forge.mysql.com/wiki/Contributing_Code

If you have comments about this procedure or would like to contribute with Replication and Backup code, please let me know.

Thursday, May 7, 2009

New Replication Features talk

In a few minutes, we will present the new replication features of 5.1 and 6.0 at the MySQL University:

Walk-through of new 5.1 and 6.0 replication features

The talk is the same as was given at the MySQL User Conference 2009.

Very welcome to join the talk!