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
On a recent consulting engagement, the PSCE team were charged with what can be considered a fairly common task of synchronising tables between master and slave in MySQL Replication. On this occasion the schema contained both foreign key constraints and triggers, this post describes how we avoided the potential problems related to such an operation.
The process to synchronise tables in MySQL is to first identify the differences between tables and then execute queries which bring those tables into a consistent state. The first part of the process can be handled by the pt-table-checksum tool, which steps through the table analysing sets of rows (chunks) and recording a checksum value. Then taking advantage of replication, the same process occurs on each of the slaves and the checksums can then be compared. Once the entire table has been processed, a second tool pt-table-sync can be used …
[Read more]High season is coming, how do you make sure that MySQL will handle the increased load? Stress tests could help with that, but it’s not a good idea to run them in a production environment. In this case Select_scan, Select_full_join and other MySQL counters could quickly give you an idea of how many queries are not performing well and could cause a performance degradation as the load goes up.
Select_scan from SHOW GLOBAL STATUS indicates how many full table scans were done since last MySQL restart. Scanning the entire table is a resource intensive operation. It also forces MySQL to store unnecessary data in the buffer pool, wasting memory and IO resources.
Full scan of a tiny table would be quite fast so missing indexes could stay invisible until the load rises or the dataset grows up. This could also be the case for developers who work with too small data sets on their dev boxes. To prevent performance issues all newly added …
[Read more]
When you're testing out a new version of MySQL in a
non-production environment there is a temptation to go wild and
turn on all kinds of new features. Especially if you're
reading the changelogs or the manual and scanning through
options. You want to start with the most reasonable set of
defaults, right? Maybe you're even doing benchmarks to
optimize performance using all the new bells and whistles.
Resist the temptation! If your goal is to upgrade your
production environment then what you really want is to isolate
changes. You want to preform the upgrade with as little to
no impact as possible. Then you can start turning on
features or making changes one-by-one.
Why? Anytime you're doing a major upgrade to something as
fundamental as your core RDBMS, there are many ways things can go
wrong. Performance regressions & incompatible changes,
client/server incompatibilities …
August 25, 2014 By Severalnines
Are you going in production with Galera Cluster for MySQL? Here are 9 tips to consider before going live. These are applicable to all 3 Galera versions (Codership, Percona XtraDB Cluster and MariaDB Galera Cluster).
1. Galera strengths and weaknesses
There are multiple types of replication and cluster technologies for MySQL, make sure you understand how Galera works so you set the right expectations. Applications that run on single instance MySQL might not work well on Galera, you might need to make some changes to the application or the workload might not be appropriate. We’d suggest you have a look at these resources:
[Read more]December 19, 2013 By Severalnines
Database clusters are pretty sophisticated distributed systems with complex dependencies between nodes. The failure of a node will generally impact the overall cluster, as the remaining nodes need to reconfigure themselves to continue to operate without the failed node. Since re-introducing a node will also affect the existing cluster, the timing could therefore be dependent on the state of the other nodes in the cluster. Repair and restarts often needs to be performed in a particular order in compliance with the redundancy model of the cluster so as not to jeopardize the normal functioning of existing nodes.
Webinar: Repair and Recovery for your MySQL, MariaDB and MongoDB/TokuMX clusters
…
[Read more]December 10, 2013 By Severalnines
As a follow-up to the Webinar on Zero Downtime Schema Changes in Galera Cluster, we’ll now walk you through the detailed steps on how to update your schema. The two methods (TOI and RSU) have both their pros and cons, and given parameters like table size, indexes, key_buffer_size, disk speed, etc., it is possible to estimate the time taken for the schema to be upgraded. Also, please note that a schema change is non-transactional so it would not be possible to rollback the DDL if it fails midway. Therefore, it is always recommended to test the schema changes and ensure you have recoverable backups before performing this on your production clusters.
This post examines the way DDL changes are propagated in Galera, and outlines the steps to upgrade the …
[Read more]November 14, 2013 By Severalnines
Database schema changes are usually not popular among DBAs or sysadmins, not when you are operating a cluster and cannot afford to switch off the service during a maintenance window. There are different ways to perform schema changes, some procedures being more complicated than others. We invited Seppo from the Codership team to tell us about the options. If you’d like to learn more, please register for our new webinar.
Webinar: Galera Cluster Best Practices - Zero Downtime Schema Changes
Tuesday, December 3rd 2013
Register now - Europe/MEA/APAC
…
[Read more]From time to time we have to work with live environments and production databases. For some of us this is day-to-day job. And most of the time cost of a mistake is way higher than expected improvement especially on the databases. Because issue on the database side will affect everything else.
I heard enough war stories about ruined productions and can imagine well enough speed of DROP DATABASE command replicating across the cluster. So I’m scared to make changes in production. The more loss expected if things go wrong the more I’m going to be scared planning every change. But I still love to make improvements so the only question is how to make them safer.
This post is not intended to be a guide or best practices on how to avoid issues at all, it’s more invitation to discussion that started between me and @randomsurfer in twitter on how to avoid production failures. …
[Read more]As a leader of a technical operations team I often have to work on technical operations engineer hiring. This process involves a lot of interviews with candidates and during those interviews along with many challenging practical questions I really love to ask questions like “What are the most important resources you think an Operations Engineer should follow?”, “What books in your opinion are must-read for a techops engineer?” or “Who are your personal heroes in IT community?”. Those questions often give me a lot of information about candidates, their experience, who they are looking up to in the community, what they are interested in, and if they are actively working on improving their professional level.
Recently, one of the candidates asked me to share my lists with him and I thought this information could be valuable to other people so I have decided to share it here on my blog.
Must-Read Books List
First …
[Read more]