Posted by francisco bordenave on Oct 14, 2011
This post was thought of as an attempt to make some performance test with new multi-threaded replication in 5.6, at least that was my initial intention. Based on Luis Soarez – Replication Team Leader in Oracle – post. I wanted to play with new set of variables and features in order to understand how new multi-threaded replication works and make some performance tests. Read the rest of this entry . . .
Posted by Ben Mildren on Sep 1, 2011
I’ve been following the development of Tungsten Replicator for quiet some time now, and recently was fortunate enough to find the time to take a look at the product in more detail.
If you haven’t heard of Tungsten Replicator yet, it’s an open source database replication engine that can be used to complement or completely replace native MySQL Replication. In addition to providing standard replication functionality, Tungsten Replicator introduces exciting new features such as global transaction IDs, heterogeneous replication from MySQL to Oracle and Postgres, parallel replication, and the ability to replicate from multiple masters to a single slave.
Read the rest of this entry . . .
Posted by Danil Zburivsky on Sep 1, 2011
MySQL Replication is a powerful tool and it’s hard to find a production system not using it. On the other hand debugging replication issues can be very hard and time consuming. Especially if your replication setup is not straightforward and you are using filtering of some kind.
Read the rest of this entry . . .
Posted by francisco bordenave on May 10, 2011
A few days ago one of our customers contact us to inform a problem with one of their replication servers.
This server was reporting this issue:
Last_Error: Could not parse relay log event entry. The possible reasons are: the master’s binary log is corrupted (you can check this by running ‘mysqlbinlog’ on the binary log), the slave’s relay log is corrupted (you can check this by running ‘mysqlbinlog’ on the relay log), a network problem, or a bug in the master’s or slave’s MySQL code. If you want to check the master’s binary log or slave’s relay log, you will be able to know their names by issuing ‘SHOW SLAVE STATUS’ on this slave.
After brief research we found the customer had deleted some binary logs from the master and relay logs from slave to release space since they were having space issues.
The customer requested us to get slave working again without affecting the production environment.
Our goal here was to figure out how to restore replication without going through an entire rebuild of slave, although this may have been the easiest solution, it had been necessary to lock the master to take a good backup, restore the binary logging, and then restore the slave of a proper replication point.
This kind of things starts to be complicated when we talk about more than 1TB to rebuild.
Unfortunately customer didn’t backed up relay-logs, but fortunately customer was backed up binary logs so that would be our starting point.
Read the rest of this entry . . .
Posted by Singer Wang on Jan 12, 2011
I’ve seen many a good DBA make the master of starting slaves from the position in the master.info file, most recently this week, that I want to bring it to everyone’s attention. Of course I mean the underlying issue and not the names of the DBA because that would be cruel. Read the rest of this entry . . .
Posted by Sheeri Cabral on Jul 27, 2010
In October 2008, Baron posted How to Check MySQL Replication Integrity Continually. Here at Pythian we have developed a method based on that post, and added “verifying that masters and slaves are in sync” to our standard battery of tests.
We call it “Continual replication sync checking”. This article will explain how it works, how to test and make the procedure non-blocking, benchmarks from the real world, issues we encountered along the way, and finally Pythian’s procedure of setting up continual replication sync in a new environment.
At the 2010 MySQL User Conference & Expo, my co-worker Danil Zburivsky did a presentation about this, and you can get the slides in ODP (Open Office) format or watch the 46-minute video on YouTube.
On the master, mk-table-checksum is run. In order to make the checksum operation online, we use the modulo and offset features of mk-table-checksum to checksum only part of the data at a time. The checksum is run (from cron) on the master and replicates to the slave. The results are captured in a result table, and a separate process checks the result table and notifies us of any discrepancies.
Read the rest of this entry . . .
Posted by Sheeri Cabral on Dec 1, 2009
OpenSQLCamp was a huge success! I took videos of most of the sessions (we only had 3 video cameras, and 4 rooms, and 2 sessions were not recorded). Unfortunately, I was busy doing administrative stuff for opensqlcamp for the opening keynote and first 15 minutes of the session organizing, and when I got to the planning board, it was already full….so I was not able to give a session.
Posted by Sheeri Cabral on Nov 25, 2009
OpenSQLCamp was a huge success! Not many folks have blogged about what they learned there….if you missed it, all is not lost. We did take videos of most of the sessions (we only had 3 video cameras, and 4 rooms, and 2 sessions were not recorded).
All the videos have been processed, and I am working on uploading them to YouTube and filling in details for the video descriptions. Not all the videos are up right now….right now all the lightning talks are up.
Read the rest of this entry . . .
Posted by Sheeri Cabral on Nov 10, 2009
Last night at the Boston MySQL User Group I presented on how to get a consistent snapshot to build a slave, how to use mk-table-checksum to check for differences between masters and slaves on an ongoing basis, and how to use tools such as mk-table-sync and mysqldump to sync the data if there are any discrepancies.
The slides are online at http://technocation.org/files/doc/slave_sync.pdf.
The video can be watched on youtube at http://www.youtube.com/watch?v=Un0wqYKmbWY or directly in your browser with the embedded player below:
Read the rest of this entry . . .
Posted by Mohammed Mawla on Mar 12, 2009
In SQL Server Replication, a regular check is getting the number of undistributed commands for a transactional subscription. This can be done using the replication monitor (SQlmonitor.exe from the RUN prompt) or programmatically by running sp_replmonitorsubscriptionpendingcmds at the Distributor on the distribution database.
One issue with sp_replmonitorsubscriptionpendingcmds is that you will have to submit a few parameters without defaults (the required parameters are mentioned in the above link).
I wanted once to get status information about all subscriptions (Last logged message, status, agent, etc.), plus the number of undistributed commands for each subscription. For the replication info there is the MSdistribution_agents table, which is stored in the Distribution database and contains one row for each Distribution Agent. For the Agents’ history there is the MSdistribution_history table, which contains the history for Distribution agents, and is also stored in the Distribution database.
To return this, my idea was to get a list of publishers, publications, subscribers, and so on, into a temporary table, loop against the result, and run sp_replmonitorsubscriptionpendingcmds for each row, and then join against MSdistribution_history for the final result.
Here it is. All comments and additions are welcome.
Read the rest of this entry . . .
