So I am getting a mail with a complaint about rising replication
delays in a certain replication hierarchy.
Not good, because said hierarchy is one of the important ones. As
in 'If that breaks, people are sleeping under the
bridge'-important.
The theory was that the change rate in that hierarchy is too high
for the single threaded nature of MySQL replication. That was
supported by the observation that all affected boxes had no local
datadir, but were filer clients. Filer clients as slaves are
dying first because the SAN introduces communication latencies
that local disks don't have, and the single threaded nature of
replication is not helpful here, either. Filers are better when
it comes to concurrent accesses, really.
So if that theory would hold that would really ruin my day. Make
that month: Said hierarchy is just now recovering from severe
refactoring surgery and should have almost no exploitable …
Come meet Tungsten replication and clustering experts. Don't miss these 5 talks:
Managing Worldwide Data with MySQL and Continuent Tungsten by Robert Hodges Replicating from MySQL to Oracle Database and Back Again by Robert Hodges MySQL High Availability: Power and Usability by Giuseppe Maxia Lessons from Managing 500+ MySQL Instances in the Cloud by Ronald Bradford Improving Performance with
Following on from my post about MySQL Cluster sessions at the forthcoming Connect conference, its now the turn of MySQL Replication - another technology at the heart of scaling and high availability for MySQL.
Unless you've only just returned from a 6-month alien abduction, you will know that MySQL 5.6 includes the largest set of replication enhancements ever packaged into a single new release:
- Global Transaction IDs + HA utilities for self-healing cluster..(yes both automatic failover and manual switchover available!)
- Crash-safe slaves and binlog
- Binlog Group Commit and Multi-Threaded Slaves for high performance
- …
[Read more]
After the GitHub MySQL Failover incident a lot of blogs/people
have explained that fully automated failover might not be the
most optimal solution.
Fully automated failover is indeed dangerous, and should be
avoided if possible. But a complete manual failover is also
dangerous. A fully automated manually triggered failover is
probably a better solution.
A synchronous replication solution is also not a complete
solution. A split-brain situation is a good example of a failure
which could happen. Of course most clusters have all kinds of
safe guard to prevent that, but unfortunately also safe guards
can fail.
Every failover/cluster should be considered broken unless:
- You've tested the failover scripts and procedures
- You've tested the failover scripts and procedures under normal load
- You've tested the failover scripts and procedures under high load …
There have been a number of excellent articles about the pros and
cons of automatic database failover triggered by Baron's post on the GitHub database outage. In the spirit of
Peter Zaitsev's article "The Math of Automated Failover," it seems like
a good time to point out that database failure is usually not the
biggest source of downtime for websites or indeed applications in
general. The real culprit is maintenance.
Here is a simple table showing availability numbers out to 5
nines and what they mean in terms of monthly down-time.
| Uptime | … |
High availability is about more than just making sure that applications can get to your data, even if there is a failure:
How about when you are upgrading your database schema What if you need to add memory to a database server or reconfigure/restart MySQL If your apps want to read data from a MySQL slave, how can you be sure they are not reading stale data without re-coding your apps What
Oracle is the most powerful database system in the world. However, Oracle's expensive and complex replication makes it difficult to build highly available applications or move data in real-time to data warehouses and popular databases like MySQL.
In this video (recording of our 9/13/12 webinar) you will learn how Continuent Tungsten solves problems with Oracle replication at a fraction of the
After a long pause in the speaking game, I am back.
It's since April that I haven't been on stage, and it is now time to resume my public duties.
- I will speak at MySQL Connect in San Francisco, just at the start of Oracle Open World, with a talk on MySQL High Availability: Power and Usability. It is about the cool technology that is keeping me busy here at Continuent, which can make life really easy for DBAs. This talk will be a demo fest. If you are attending MySQL Connect, you should see it!
- A happy return for me. On October 27th I will talk about open source databases and the pleasures of command line operations at …
In this blog post I will show you how to setup a replication from
MySQL Cluster (ndbcluster) to a regular MySQL Server
(InnoDB). If you want to understand the concepts, check out part
7 of our free MySQL Cluster training.
First of all we start with a MySQL Cluster looking like this, and
what we want to do is to setup replication server to the
Reporting Server (InnoDB slave).
MySQL Cluster is great at scaling large numbers of write
transactions or shorter key-based read querise, but not so good
at longer reporting or analytical queries. I generally recommend
people to limit analytical/reporting queries on the MySQL
Cluster, in order to avoid slowing down the …
Oracle is the most powerful database system in the world. However, Oracle's expensive and complex replication makes it difficult to build highly available applications or move data in real-time to data warehouses and popular databases like MySQL.
In this webinar you will learn how Continuent Tungsten solves problems with Oracle replication at a fraction of the cost of other solutions and