Recently, I have worked on one of this case where customer wanted to convert master-slave to master-master replication. They wanted to write on one master and keep another master as a hotspare. Many people are using this kind of environment with MySQL replication.

I would like to explain here in very simple steps that how we can do that. You can also follow the same steps if you want to promote only slave as a master in master-slave replication. Sometimes, this process will be helpful if you have master-slave replication and you want to rebuild or upgrade both the servers one by one. In that case, you have to shift traffic from one server to the other, take down the first server, rebuild it and then reverse the process.

I would also like to mention here that  master-master (active-active) replication is quite risky and it can lead to data inconsistency between the servers if writes are enable on both masters at the same time. …

Many CMS-backed sites are built using MySQL and are launched on cloud infrastructure. In order to mitigate down-time due to regional outages, it is advisable to create a geo-distributed redundancy topology in both the app layer as well as within the database. GenieDB makes it very easy to set up multiple MySQL database servers around the world that are automatically kept synchronized as data is changed on any of the nodes. The database nodes are typically paired 1-on-1 with an app or web server. Some of our customers use the app servers to dish out their CMS backed sites. The database is kept synchronized, but the customers still need to find a way to keep the media content that they use to be available on all these app/web servers. Below is a simple setup that can be easily configured within a very small budget and provides high availability for both the data and the static content during an outage.

While some of our customers use …

Two of the more popular solutions are  MySQL Master HA and Percona Replication Manager.

MySQL Master HA

MHA is based on a set of Perl scripts that monitors for replication and server health. When a failover scenario will happen, it can do automatic failover to a slave OR from a selection of slaves you have configured to make as the new master. The good thing about this is, after the initial failover, there will be no succeeding attempts to fail back, this is to protect your data and consistency of the cluster. You can also configure to only have manual failover for scheduled maintenance and the like. Between PRM and MHA, MHA is really easier to manage.

http://code.google.com/p/mysql-master-ha/

Percona Replication Manager

PRM is based on …

Catching up on our reading today, we saw a blog post from Chris Stevens, the multi-faceted VP of Engineering at Traxo, technology consultant, and Full Stack developer. In his post, he notes some of the impressive new database technologies he’s seeing lately in tech blogs and on the conference circuit.

Chris says that when it makes sense he advises his clients to look at non-relational datatstores, but for a number of reasons he works with MySQL wherever possible. Many of his clients looking to run globally distributed applications often need to distribute the database across more than one data center (geo-distribution) for fault tolerance and localized performance.

“Globally distributed applications often require localized performance,” he said in his post. “We can do some work loading front-end assets from CDN …

Standard MySQL is configurable such that a single master server can be clustered with a number of read-only slave servers. To enable this master-slave replication, master’s transaction logs are communicated to the slaves (log shipping). Log shipping is a form of asynchronous replication. Under this configuration, the data on the slave always remains behind the master, a condition referred to as slave lag or replication lag. The extent of the slave lag depends on workload, network bandwidth and network latency. Database reads can be served out of the slaves, assuming the application has been designed to tolerate the slave lag and requisite staleness of data (eventual consistency), which can at times be variable and opaque. MySQL master-slave replication offers the possibility of promoting a slave to become the new master should the master fail, but this is very painful to do in practice. The cluster has to stop taking ANY writes while it waits for …

Scenario Master – Master replication

MasterA is a client facing server
MasterB is a warm standby server (read only)

MasterB restarted abruptly and when instances were braught back up MasterA (it’s slave) was showing the following error:

MasterA has the following error in show slave status:
Last_IO_Errno: 1236
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘Could not find first log file name in binary log index file’

Solution:

Slave: stop slave;

Master: flush logs
Master: show master status; — take note of the master log file and master log position

Slave: CHANGE MASTER TO MASTER_LOG_FILE=’log-bin.00000X′, MASTER_LOG_POS=106;
Slave: start slave;

At times you need to install multiple MySQL instances on same machine. This article is a brief step-by-step tutorial on the subject task which is divided into the following main…

The post Install 2 MySQL Server instances replication on Windows first appeared on Change Is Inevitable.

“Show Slave Status” command has a last column “Seconds_Behind_Master”, which gives us idea about how much time slave is lagging behind master. It is an important to be considered parameter…

The post Replication slave lag monitoring using heartbeat and windows batch scripts first appeared on Change Is Inevitable.

It’s been a long time since we’ve started this project and it is time to make a checkpoint. So, I’ve decided to release final 1.0 version and make 1.X branch stable while all serious development with deep architectural changes will be done 2.X branch (trunk at this moment).

Changes from previous release:

• Perl semaphores implementation caused huge memory leaks (mmmd_mod).
• Now we do not send any commands to hard offline hosts with dead TCP/IP stack to prevent mointoring problems for other hosts.
• Removed legacy StartSlave method from agent code which caused problems on some Perl versions
• Added a few fixes to prevent non-exclusive roles from moving. This caused internal status structures to …

MySQL Master-Master Replication Manager version 1.0-pre3 has been released today. Changes list is really short now:

• Major fix in multiple clusters support - now you can use many clusters with one monitoring node (details are in mmmd_mon man page)
• Man pages for mmmd_mon, mmmd_agent and mmm_control scripts
• Startup scripts added/fixed for mmmd_mon and mmmd_agent
• Installation script now requires iproute package to be installed on server.

As always, if you have any questions/suggestions, post them here or in mmm-devel mail list.