Note: DO NOT use this procedure in production, this is a proof of concept (POC). MaxScale 1.1.0 does not yet fully support that procedure and things could go wrong in some situations (see at the end of the post for the details).
In my talk at PLMCE 2015, I presented an architecture to promote a slave as a new master without touching any other slave and I claimed that I tested it. This HOWTO
In the Install and Configure HOWTO, we learned how to install and configure a MaxScale Binlog Server. In this HOWTO, I will present the common operations that you might need to perform when using this software. Those operations include:
Purging Binary Logs, Chaining Binlog Servers, Saving Binary Log Files in the Non-Default Directory, Downloading Binary Logs other than First, Listing Connected
One year ago, I blogged about Evaluation and Online Migration of MySQL 5.6 GTIDs. At that time, we setup the following test environment where:
A is a production master with GTIDs disabled, D to Z are standard slaves with GTIDs disabled, B is an intermediate master running my recompiled version of MySQL implementing the ANONYMOUS_IN-GTID_OUT mode (see the details my previous post), C is a slave
If table is partitioned then that makes
it easy to maintain. Table has grown so huge and the backups are
just keep running long then probably you need to think of
archival or purge.
Purge the data if you don't want data from old partitions
just by doing truncate or drop of those partitions which
completes momentarily without locking the table for a long
time
Archival can be done couple of ways.
We can take mysqldump (preferably from a slave) with a
where condition to filter out the data you don't want to copy.
And then import the dump file to archive database. check this
link out for mysqldump with where clause .. and once data is
copied, the …
MySQL 5.6.23 was recently released (it is the latest MySQL 5.6, is GA), and is available for download here.
For this release, there is 1 “Security Note”, 3 “Functionality Changed”, and 5 “Compilation Notes”, all benign, but let me address them:
MySQL 5.6.22 was recently released (it is the latest MySQL 5.6, is GA), and is available for download here.
For this release, there is 1 “Security Note”, 2 “Functionality Changed”, and 5 “Compilation Notes”, all benign, but let me address them:
So assume you just uploaded the certificate you use to identify
yourself to the MySQL server to Github or some other place it
doesn't belong...and there is no undelete.
First: Don't panic.
Often a password is required besides a certificate to connect to
the server. So someone with the certificate can't use it without
the password. The certificate itself might be protected by a
password, but that's really rare. Also access to MySQL and/or
your account should be limited to certain IP's.
The next step is to revoke the certificate. This is possible
since MySQL 5.6.3 by using a Certificate Revocation List
(CRL).
A CRL is a list of the serials of the revoked certificates and
signed by the CA. So this will only work if the certificates have
unique serials.
…
It struck me today; there is an easy way to describe MySQL's Binary Log group commit improvements from MySQL 5.0-5.7 by using the example of a single ferry trying to ship passengers from point A to point B:
MySQL 5.0 Behaviour
In MySQL 5.0, the ferry will pick up the next passenger in line from point A, and transfer them to point B. The trip between A and B takes about 10 minutes return trip, so it's possible that several new passengers will arrive while the ferry is in transit. That doesn't matter; when the ferry arrives back at point A, it will only pick up the very next passenger in line.
MySQL 5.6 Behaviour
In MySQL 5.6, the ferry will pick up all passengers from the line at point A, and then transfer them to point B. Each time it returns to point A to pick up new passengers, it will collect everyone who is …
[Read more]It has been a while since I have looked at InnoDB crash recovery. A lot has change in the last few years – we have serious crash recovery performance improvements in MySQL 5.5 and MySQL 5.6, we have solid state drives raising as typical high performance IO subsystem and we also have the ability to set much larger log files and often have a much larger InnoDB Buffer Pool to work with.
First let me revisit the challenge with have with InnoDB configuration. For write-intensive workloads it is extremely important to size innodb_log_file_size for good performance, however the longer log file size you have the longer you might have to wait for InnoDB to complete crash recovery, which impacts your recovery strategy.
How much can innodb_log_file_size impact performance? Massively! Doing intensive writes to a database that well fits in memory, I’d say there’s a 10x …
[Read more]There were two nasty MySQL replication bugs in two different 5.6 releases that would make it difficult to upgrade slaves to MySQL 5.6 while still connected to MySQL 5.5 master. The first of those bugs is MySQL bug 72610 which affects 5.6.19. Essentially this bug is triggered when the table structure on the slave is different from the table structure on the master which leads to unnecessarily large amount of RAM usage while replicating events that affect that table. The amount of RAM used would generally be more noticeable when the replicated transaction consists of thousands of RBR events. The most common way this affects how we upgrade a replication hierarchy, is when we have the master running MySQL 5.5 and the slave running MySQL 5.6 and we have transactions involving DATETIME column(s). Tables with DATETIME columns will have different underlying structure when created on MySQL 5.5 versus when created on MySQL 5.6. Ideally you would avoid creating …
[Read more]
