Now it's time to get serious about replicating to MariaDB from
Oracle, and we are real close now, right? What I needed was a
means of keeping track of what happens in a transaction, such as
a LOG table of some kind, and then an idea of applying this log
to MariaDB when there is a COMMIT in Oracle. And thing is, these
two don't have to be related. So I can have a table which I write
to and also have a Materialized View that is refreshed on COMMIT
on, and I need a log table or something. And when the
Materialized View is refreshed, as there is a COMMIT, then the
log can be applied. From a schematic point-of-view, it looks
something like this:
This looks more complex than it is, actually,
all that is needed is some smart PL/SQL and this will work. I
have not done much of any kind of testing, except checking that
the basics …
The latest from the MySQL community
Ideas, releases, practical guides, and perspectives from the people building with MySQL.
In this third installment in this series, I'll explain why the
smart solution I described in the previous post actually wasn't that good, and
then I go on to explain how to fix it, and why that fix wasn't
such a smart thing after all. So, this was the design we ended
with last time:
We have Oracle replicating to a Materialized
View, this to ensure that we can run triggers when the is a
commit, and then triggers on this Materialized View updates
MariaDB by sending a UDP message to a server that in turn is
connected to MariaDB.
The issue with the above thingy was that a Materialized View by
default is refreshed in it's entirety when there is a refresh, so
if the table has 10.000 rows and 1 …
The theme for this series of posts is, and indicated in the
previous post, "Try and try, again", and there
will be more of this now when I start to make this work by
playing with Oracle, with PL/SQL and with the restrictions of
Oracle Express (which is the version I have available).
So, what we have right now is a way of "sending" SQL statements
from Oracle to MariaDB, the question is when and how to send them
from Oracle. The idea for this was then to use triggers on the
Oracle tables to send the data to MariaDB, like this, assuming we
are trying to replicate the orders table from Oracle to
MariaDB:
In Oracle, and assuming that the
extproc I have that created to send UDP …
Yes, there is a simple way to do this. Although it might not be
so simple unless you know how to do it, so let me show you how
this can be done. It's actually pretty cool. But I'll do this
over a number of blog posts, and this is just an introductory
blog, covering some of the core concepts and components.
But getting this to work wasn't easy, I had to try several things
before I got it right, and it's not really obvious how you make
it work at first, so this is a story along the lines of "If at
first you don't succeed mr Kidd" "Try and try again, mr
Wint" from my favorite villains in the Bond movie "Diamonds
are forever":
So, I had an idea of how to achieve replication from Oracle to
MySQL and I had an idea on how to implement it, and it was rather
simple, so why not try it.
So, part 1 then. Oracle has the ability to let you add a
UDF (User Defined Procedure) just like MariaDB (and
MySQL), …
September 26, 2014 By Severalnines
Paytrail is a leading e-payment method provider from Finland, and is expanding globally. Established in 2007, Paytrail currently has over 4,000 business customers, works with over 350 partners and its solution is available in all SEPA (Single Euro Payments Area) countries.
Paytrail offers a new online shopping solution that allows consumers to use one login for all of their online purchases. And it provides everything that is needed for online shopping in addition to traditional payment methods (bank e-payments, credit and debit card payments, invoicing and installments).
This new case study describes how Paytrail came to work with Severalnines to achieve a fault-tolerant database cluster across two data centers.
|
… |
MySQL 5.5.40 was recently released (it is the latest MySQL 5.5, is GA), and is available for download here:
http://dev.mysql.com/downloads/mysql/5.5.html
This release, similar to the last 5.5 release, is mostly uneventful.
There were 0 “Functionality Added or Changed” bugs this time, and 18 bugs overall fixed.
Out of the 18 bugs, most seemed rather minor or obscure, but there are 3 I think are worth noting (all 3 are InnoDB-related, regressions, and serious if you encounter them, so best to be aware of them):
- InnoDB: An ALTER TABLE … ADD FOREIGN KEY operation could cause a serious error. (Bug #19471516, Bug #73650)
- InnoDB: With a transaction isolation level less than or equal to READ COMMITTED, gap locks …
The biggest innovation in TokuDB v7.5 is Read Free Replication (RFR). I blogged a few days ago posting a benchmark showing how much additional throughput can be achieved on a replication slave, while at the same time lowering the read IO operations to almost zero. The official documentation on the feature is available here.
In this second blog I want to cover the requirements for RFR, as well as some interesting use-cases for the technology.
RFR Requirements The only requirement on the master is that …[Read more]September 25, 2014 By Severalnines
Coming up with a backup strategy that does not affect database performance or lock your tables can be tricky. How do you backup your production database cluster without affecting your applications? Should you use mysqldump or Percona Xtrabackup? When should you use incremental backups? Where do you store the backups? In this blog post, we will cover some of the common backup methods for Galera Cluster for MySQL/MariaDB, and how you can get the most out of these.
Backup Method
There are various ways to backup your Galera Cluster data:
- xtrabackup (full physical backup)
- xtrabackup (incremental physical backup)
- mysqldump (logical backup)
- binary logging
- replication slave
Xtrabackup (full backup)
Xtrabackup is an open-source MySQL hot …
[Read more]New to TokuDB® v7.5 is a feature we’re calling “Read Free Replication” (RFR). RFR allows TokuDB replication slaves to process insert, update, and delete statements with almost no read IO. As a result, the slave can easily keep up with the master (no lag) as well as brings all the read IO capacity of the slave for read-scaling your workload.
The goal of this blog is two-fold: (1) to cover why RFR is important and how RFR works and (2) to run a simple before/after benchmark showing the impact of RFR on a well known workload. Later this week I’ll post another blog showing other interesting use-cases for RFR beyond this first benchmark.
Read Free Replication: The Why and How
In MySQL, a replication slave does less work than the master because there is no need for a slave to execute SELECT statements (only INSERT, UPDATE, and DELETE). However, a MYSQL slave can struggle to keep up with the master because replication is …
[Read more]September 22, 2014 By Severalnines
Need to add phone and SMS alerting to ClusterControl? ClusterControl 1.2.8 introduces support for PagerDuty, an alerting service for Ops teams to schedule on-calls and add phone and SMS notifications to IT tools. By integrating PagerDuty with ClusterControl, you can start receiving phone, SMS and email notifications for all important database events as monitored by ClusterControl. Alerts go directly to the right person who can solve the issue.
This integration is possible thanks to a new plugin interface, that takes ClusterControl alarms in JSON format and outputs to an external system via plugins. Plugins can be either scripts or executable binaries.
We have built a few example …
[Read more]