This blog post is a follow up to our previous post on monitoring CPU-related InnoDB metrics in Galera Cluster. 

One of the main issues in terms of scalability of MySQL (and thereby also Galera) is the ability to handle large amounts of I/O activity. MySQL, historically, was not very good in this area - flushing caused bumps and spikes in the workload, and kernel mutex was wrecking havoc in the overall stability. I/O handling changed in MySQL 5.5 and has been improved even further in MySQL 5.6. Multiple background threads for I/O, adaptive approach to flushing data, splitting the kernel mutex into a number of new mutexes and rw-locks. Even with all those changes, checking MySQL I/O metrics is a very important part of the daily routine.

How InnoDB saves data …

MySQL replication isn’t perfect and sometimes our data gets out of sync, either by a failure in replication or human intervention. We are all familiar with Percona Toolkit’s pt-table-checksum and pt-table-sync to help us check and fix data inconsistencies – but imagine the following scenario where we mix regular replication with the Tungsten Replicator:

We have regular replication going from master (db1) to 4 slaves (db2, db3, db4 and db5), but also we find that db3 is also master of db4 and db5 using Tungsten replication for 1 database called test. This setup is currently working this way because it was deployed some time ago when multi-source replication was not possible using regular MySQL replication. This is now a working feature in …

The VividCortex brainiacs continue taking strides toward better database monitoring, one feature at a time. See our 2015 highlights here and contact us to see how we can improve your IT efficiency.

Restore hackmysql.com/case1: Indexing Basic MySQL Queries.

This is a new release with some new features and many bugfixes and enhancements.

Get it from the download page.



Changelog:
* New feature: Add support for JSON grid export
* New feature: Add support for Markdown Here grid export
* New feature: Support new command line parameter "n", or "nettype", which takes an integer, representing the protocol number (0=mysql tcpip, ...).
* New feature: Add support for connecting to Microsoft Azure Servers
* New feature: Add edit box + updown buttons for limiting the size of exported INSERT queries in bytes.
* New feature: Display creation time, last alter time, comment and start time of scheduled events.
* New feature: Online help document …

This is a new release with some new features and many bugfixes and enhancements.

Get it from the download page.



Changelog:
* New feature: Add support for JSON grid export
* New feature: Add support for Markdown Here grid export
* New feature: Support new command line parameter "n", or "nettype", which takes an integer, representing the protocol number (0=mysql tcpip, ...).
* New feature: Add support for connecting to Microsoft Azure Servers
* New feature: Add edit box + updown buttons for limiting the size of exported INSERT queries in bytes.
* New feature: Display creation time, last alter time, comment and start time of scheduled events.
* New feature: Online help document …

Is It Supported for MAC Versions??

I used this technique to remove strings from bash history file containing passwords and other sensitive data on a Mac OS X shell.

Wonder how MySQL Slave server will act, when disk full condition occurs? Before in our articles we use only single MySQL server. Now think about replication topology, where slave server has problem with full partition. Firstly we will enable Binary Log/GTID on Slave side and will ensure that the changes also applied to binary log on Slave side:

      # BINARY LOGGING # 
      server_id = 2 
      log_bin = /opt/mysql/datadir/mysql-bin 
      log_bin_index = /opt/mysql/datadir/mysql-bin 
      expire_logs_days = 14 
      sync_binlog = 1 
      binlog_format = row 
      relay_log = /opt/mysql/datadir/mysql-relay-bin 
      log_slave_updates = 1 
      read_only = 1 
      gtid-mode = on 
      enforce-gtid-consistency = true 
      master-info-repository = TABLE 
      relay-log-info-repository = TABLE 
      slave-parallel-workers = 15 
      binlog-checksum = CRC32 
      master-verify-checksum = 1 
      slave-sql-verify-checksum = 1 …

An idea for a benchmark based on the “arrival request” rate that I wrote about in a post headlined “Introducing new type of benchmark” back in 2012 was implemented in Sysbench. However, Sysbench provides only a simple workload, so to be able to compare InnoDB with TokuDB, and later MongoDB with Percona TokuMX, I wanted to use more complicated scenarios. (Both TokuDB and TokuMX are part of Percona’s product line, in the case you missed Tokutek now part of the Percona family.)

Thanks to Facebook – they provide LinkBench, a benchmark that emulates the social graph …