Before getting to the details of how eventual consistency is
implemented, we need to look at epochs. Ndb Cluster maintains an
internal distributed logical clock known as the epoch,
represented as a 64 bit number. This epoch serves a number of
internal functions, and is atomically advanced across all data
nodes.
Epochs and consistent distributed state
Ndb is a parallel database, with multiple internal transaction
coordinator components starting, executing and committing
transactions against rows stored in different data nodes.
Concurrent transactions only interact where they attempt to lock
the same row. This design minimises unnecessary system-wide …
For the impatient ones, or ones that prefer code to narrative, go here. This is long overdue anyway, and Yoshinori already beat me, hehe…
Our database environment is quite busy – there’re millions of row changes a second, millions of I/O operations a second and impact of that can be felt at each shard. Especially, as we also have to replicate to other datacenters, single threaded replication on MySQL becomes a real bottleneck.
We use multiple methods to understand and analyze replication lag composition – a simple replication thread state sampling via MySQL processlist helps to understand logical workload components (and work in that field yields great results), and pstack/GDB …
[Read more]
I was at an event recently and the topic of replication stirred
the curiosity of the audience. A few audience members had Master
to Master but they wanted to move away from that. Others had
multiple slaves but wanted little downtime and backend work if a
master failed. Relayed replication or a database chain is an
option to solve some of their issues. Another option would be
Cluster but it depends on your infrastructure, budget and
application, some of them are looking into this as well. Is
a chain the best solution for everyone, of course not. While I
cannot do consultant work to help them, I can blog about it…
A relayed replication environment allows you to, of course, have replicated databases but also have a replication environment that is still available if or when the master …
[Read more]
What do cruise ship management software and data warehouses have
in common? One answer: they both depend on
intermittent data replication. Large vessels collect data
to share with a home base whenever connectivity permits. If
there is no connection, they just wait until later. Data
warehouses also do not replicate constantly. Instead, it is
often far faster to pool updates and load them in a single
humongous batch using SQL COPY commands or native loaders.
Replicating updates in this way is sometimes known as
batch replication. Tungsten Replicator supports it quite
easily.
To illustrate we will consider a Tungsten master/slave
configuration. (Sample setup instructions …
Working with replication, you come across many topologies, some of them sound and established, some of them less so, and some of them still in the realm of the hopeless wishes. I have been working with replication for almost 10 years now, and my wish list grew quite big during this time. In the last 12 months, though, while working at Continuent, some of the topologies that I wanted to work with have moved from the cloud of wishful thinking to the firm land of things that happen. My quest for star replication starts with the most common topology. One master, many slaves.
Fig 1. Master/Slave topology |
Legend |
It looks like a star, with the rays extending from the master to the slaves. This is the basis of most of the replication going on mostly everywhere nowadays, and it has few surprises. Setting aside the …
[Read more]
Tungsten parallel apply on slaves, or parallel replication for
short, has been available for about a year. Until recently
we did not have many formal benchmarks of its performance.
Fortunately the excellent Percona
Live Conference in London accepted my talk on Tungsten
parallel replication (slides available here), so Giuseppe
Maxia and I finally allocated a block of time for systematic
performance testing.
In a nutshell, the results were quite good. In the best
cases Tungsten parallel apply out-performs single-threaded native
replication by about 4.5 to 1. Both Giuseppe and I have
verified this using slightly different test methodologies, which …
In the recent few weeks I have spent some time for creating yet
another slave prefetching tool named "Replication Booster (for
MySQL)", written in C/C++ and using Binlog API. Now I'm happy to say that I have
released an initial version at GitHub repository.
The objective of Replication Booster is same as mk-slave-prefetch: avoiding or reducing
replication delay under disk i/o bound workloads. This is done by
prefetching relay logs events, converting to SELECT, and
executing SELECT before SQL Thread executes the events. Then SQL
thread can be much faster because target blocks are already
cached.
On my benchmarking environment Replication Booster works pretty …
In my previous posts I introduced two new conflict detection
functions, NDB$EPOCH and NDB$EPOCH_TRANS without explaining how
these functions actually detect conflicts? To simplify the
explanation I'll initially consider two circularly replicating
MySQL Servers, A and B, rather than two replicating Clusters, but
the principles are the same.
Commit ordering
Avoiding conflicts requires that data is only modified on one
Server at a time. …
Blackhole tables are often used on a so-called “relay slave” where some operation needs to happen but no data needs to exist. This used to have a bug that prevented AUTO_INCREMENT columns from propagating the right values through replication, but that was fixed. It turns out there’s another bug, though, that has the same effect. This one is caused when there is an INSERT into a Blackhole table, where the source data is SELECT-ed from another Blackhole table.
I think it’s wise to keep it simple. MySQL has tons of cool little features that theoretically suit edge-case uses and make ninja tricks possible, but I really trust the core plain-Jane functionality so much more than these edge-case features. That’s precisely because they often have some edge-case bugs, especially with replication.
…[Read more]
Typical MySQL environment involves one Master receiving writes
and multiple slaves to scale the reads. The “slave” term has been
used in MySQL because the Slave servers have to perform every
task in copying from the Master binlog, then updating their relay
logs and finally committing to the Slave databases. The Master
plays no role in replication here other than storing the
replication events in the binlog.
With this kind of Master- Slave set up, there are several
limitations-
- Slave lag
- Stale or old data
- Data loss
- Manual failover which is
error-prone and time consuming
In SchoonerSQL, there is no concept of “Slaves” inside
synchronous cluster. We refer to it as "Read Masters" because of
our synchronous approach and different replication architecture.
It is …