When dealing with replicated setups with two or more slaves sharing a master, it appears as if a lot of people overlook the obvious. You don't need to take your master down to resync a slave. I was hoping I wouldn't need to post about this, but I see people taking down their masters when they have perfectly healthy slaves way too often to let it slip.
Replication is one of the most flexible technologies available
for databases. We are implementing a new open-source,
database-neutral replication product that works with MySQL,
Oracle, and PostgreSQL. Naturally we've done a lot of thinking
about the feature set. It's tough to pick any single feature as
the most important, but one that really stands out is optional
statement replication. Here's why.
Database replication products tend to replicate row changes and
DDL. However, Mark Callaghan has a great example of why you want to replicate
statements as well--it enables Maatkit distributed consistency checking to
work. If you dissect the …
Few days back, one of my colleagues posted a good question. It sounds something like this;
"Temporary tables are session based that means under different sessions we can create temporary tables with similar names. Now since slave thread is singleton, how does it manage to keep them separate?"
He was very much right in asking this and the answer is not all that intuitive. Lets go through the binlog events to see why it is not that intuitive.
1: mysql> SHOW BINLOG EVENTS IN 'log-bin.000016';
2: . . .
3: | log-bin.000016 | 389 | Query | 2515922453 | 488 | use `test`; CREATE TEMPORARY TABLE test.t(a int) |
4: | log-bin.000016 | 488 | Query | 2515922453 | 582 | use `test`; INSERT INTO test.t(a) VALUES(1) |
5: | log-bin.000016 | 582 | Query | 2515922453 | 676 | use `test`; INSERT INTO test.t(a) VALUES(3) …[Read more]
Contrary to what I said earlier, Falcon has decided to deliberately disable statement-based replication using the same capabilities mechanism that InnoDB uses.
The reason is that isolation between concurrent transactions cannot be guaranteed, meaning that two concurrent transactions are not guaranteed to be serializable (the result of a concurrent transaction that has committed can "leak" into an ongoing transaction). Since they are not serializable, it means they cannot be written to the binary log in an order that produce the same result on the slave as on the master.
However, when using row-based replication they are serializable, because whatever values are written to the tables are also written to the binary log, so if data "leaks" into an ongoing transaction, this is what is written to the binary log as …
[Read more]I found myself with some spare time the other day and decided that my current mysql backup strategy is not the best in the world. The mysql server is a virtual machine in a Brisbane datacenter and it's backed up via a script that calls mysqldump on each installed database and dumps the content to (compressed) files. These files then get sucked down via rdiff-backup.
This is fine in principle, but does mean it's possible for me to lose 24 hours worth of data due to an accidental '--; DROP table students.
A more ideal way would be for the remote sql server to replicate to a local one, on which I can run mysqldump more often without affecting web site performance. (Replication would replicate the DROP table statement too.. :-)
With a bit of a confluence of attending three days of OpenQuery mysql training and needing to regenerate all ssl keys, I thought I should …
[Read more]
The PostgreSQL community is getting really serious about
replication. On Thursday May 29th, Tom Lane issued a manifesto concerning database replication on
behalf of the PostgreSQL core team to the pgsql-hackers mailing list. Tom's post basically
said that lack of easy-to-use, built-in replication is a
significant obstacle to wider adoption of PostgreSQL and proposed
a technical solution based on log shipping, which is already a
well-developed and useful feature.
What was the reaction? The post generated close to 140 responses
within the next two days, with a large percentage of the
community weighing in. It's one of the most significant
announcements on the list in recent history. …
Over the past few years of dealing with mysql in larger environments, one thing I’ve always felt that ALTER TABLE statements are flaky with replication, but could never really prove it. I never had a chance to dig into some of strange things I saw, and would tend to overlook and fix them
While working for a client, I encountered an issue that I could no longer ignore. In order to reload a small table from a master database to a number of slaves, I simply piped the output of mysqldump into the master and expected everything to flow into the slaves.
The bug is very specific, and probably not very common. If you send a statement like below, as mysqldump automatically adds, to your master:
/*!40000 ALTER TABLE table_name DISABLE KEYS */;
and have configured something like
replicate-rewrite-db=mydb->mydb_slave
on …
[Read more]Properties:
Applicable To | MySQL Server |
Introduced In | 5.1.5 |
Server Startup Option | --binlog-format=<value> |
Scope | Both |
Dynamic | Yes |
Possible Values | enum(ROW, STATEMENT, MIXED) |
Default |
< 5.1.12: STATEMENT >= 5.1.12: MIXED |
Categories | Replication, Performance |
Description:
Starting with 5.1.5, MySQL has implemented ROW based replication format which logs the physical …
[Read more]There is much discussion of why MySQL is more widely adopted than PostgreSQL. The discussion I’ve heard is mostly among the PostgreSQL community members, who believe their favorite database server is better in many ways, and are sometimes puzzled why people would choose an inferior product.
There are also many comparison charts that show one server is better than the other in some ways. These don’t really seem to help people with this question, either!
I can’t answer for everyone, but I can put it in the form of a question: if I were to replace MySQL with PostgreSQL, what things do I rely on that would become painful or even force a totally different strategy? The answer turns out to be fairly simple for me: replication and upgrades.
Replication
Love it or hate it, MySQL’s built-in replication is …
[Read more]I've uploaded MySQL Replication Manager's (mysqlreplicationmanager) screenshot and Screencast
Video / Screencast
You can download a full size video from here.