Basically I want to setup a replication server for mysql datbase. I am completely new to this concept and appreciate any help pointing me in the right direction.
If at all the slave goes down, will it effect the master in anyway?
Thanks.
No, it will not affect the master if the slave goes down. The Slaves connect to the master and request the changes.
If you intend on having 2 servers replicated, then you can use Master-Master replication. This means that either one of the database servers can go down without loss of data or access. This is extremely resilient to failure however you can get duplicate key errors on fast successive inserts, like using MySQL to handle sessions. This can be solved programatically through.
The downside of the Master-Slave set up is that if the master fails you have to manually assign another Master, fix the failed master and then bring back into the group. Otherwise failure of any or all Slaves will not affect the Master.
Related
Weird question I know. I have a master MySQL database which I'm not allowed to touch and need to build a slave for. I would like the slave to be as real time (as possible) of a replica of the master and would like the slave to be HA.
Does MySQL (or MariaDB) replication work when run on a cluster, say, can I make a Galera cluster and make it replicate from a master out of the box or must I use binlog-esque tools?
For the curious; this new slave cluster will be on a different network and will have many large, important queries made against it regularly - the aim of the game is to reduce load on the master and reduce network traffic.
If you are not planning on doing modifications to the downstream slave server, then you can just set up multiple slave servers. This way if one of the slaves goes down you can use another one. This will place a small load on the master for each added slave but whether this added load is even measurable depends on your setup.
Galera could work but I believe you would have to reconfigure one of the nodes to act as the slave if the current one goes down. This would place a minimal load on the master but it would require a manual intervention whenever the current "slave" node goes down.
Parallel replication should also help speed up replication for MariaDB servers.
We have successfully set up a Master-Slave replication as described in MySQL literature.
However, I'm curious if anyone has set up a bidirectional replication. For example, if one has a Drupal or Wordpress installation. The first ('master') database server goes down, and the secondary ('slave') picks up. All the while, users continue to make edits, writing new data. When the First database server is restarted, can changes written to the Second be replicated upward to the First?
That is: are there other replication strategies than only the Master-Slave?
You can do Master-Master replication. Unfortunately, Neither Drupal or Wordpress support this. The best thing to do is Master-Slave or Master-Slave-Slave, then make the first slave in the chain the new Master if the original master goes down. Then reconfigure the old Master to slave off the new Master (or last slave in the chain).
How often does your mysql server go down?
Master-Master Replication has some disadvantages. For example data inconsistencies can easily occur.
Have you tried synchronous multi-Master Replication with Galera Cluster for MySQL?
http://codership.com/
I read some article about how to implement high-availability solution,the use Heartbeat to check the master mysql is broken,if it broken then switch to the backup server,
one question is when the master server broken,the backup server work on ,how the backup server get the master server 's pre-data
another question is maybe sometimes the master server is not broken,but the mysql service is broken,in this situation is Heartbeat still will switch to the backup server?
What you usually want to do is setup a master-master configuration, but generally only use one master. That was each master also acts as a slave to the other master. In theory, you can modify records in either one and they will keep in sync. In practice, I wouldn't do heavy updates on both servers at once.
My current setup is a master-master configuration, with each master also having a slave off of it. Then you can "failover" to the secondary master/slave and "fail back" when needed. I actually do this if I have database modifications that will take a while.
I have a scenario where there are multiple mysql 4.x servers. These databases were supposed to be replicating to another server. After checking things out on a slave it appears that this slave has not replicated any databases in some time.
Some of these databases are > 4G in size and one is 43G(which resides on another server). Has anyone out there replicated databases without creating a snapshot to copy over to a slave? I cannot shutdown the master server because of the downtime. It will probably take over an hour and 40 minutes to create a snapshot. So this is out of the question.
I was going to perform a load data from master on the slave to pull everything from scratch. Any idea how long this will take on databases ranging from 1-4G and the 43G database will be for another day. All of the tables on the master are myIsam so I don't think I will have a problem with the load from master method.
What are the best methods on the slave to clean things up or reset things so I can just start from a clean slate?
Any suggestions?
Thanks in advance
You need a snapshot to start replication. Snapshots require either the database to be locked (at least) read-only. So you can have a consistent place to start from.
Downtime is a necessary thing, customers usually understand it as long as it doesn't happen too often.
Is there any way to get a fault tolerant MySQL replication? I am in an environment that has many networking issues. It appears that replication gets an error and just stops. I need it to continue to work and recover from these faults. There is some wrapper software that checks the state of replication and restarts it in the case of losing its log position. Is there an alternative?
Note:
Replication is done from an embedded computer with MySQL 4.1 to a external computer that has MySQL 5.0.45
What error are you getting? You also haven't described what replication scheme or Mysql version you're using. The errors you're getting are also important.
Replication usually stops when there's a primary/unique key conflict in a Master-Master replication. Other than that on a typical Master-Slave replication setup, networking issues shouldn't cause problems.
Try using Mysql 5.1 or newer, since replication in 5.0 is statement-based and causes problems in Master-Master setups, or when you're using stored-procedures.
(Also, stay away from Mysql Cluster ... noticed the advice on another comment).
Replication errors only happen if the databases get out of sync somehow, having the server simply continue would mean incoherent databases, I really doubt you'd want that.
In my experience, the only time you end up with such errors is if one of the master servers did not complete a query and the slave noticed.
In any case, if you really want to have the slave continue via some sort of chron job, you could always have a query run every few minuts asking the slave "SHOW SLAVE STATUS" then checking the error column, if it's present, send a "STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER; START SLAVE;" command. But it would probably be much more apt to send an email to an admin when mysql encounters an error instead, so he/she can investigate the source of the problem and make sure the databases are actually in sync, otherwise you're likely to see more errors in the near future as the databases become more and more out of sync.
Consider MySQL Cluster using the NDB storage engine, it's meant to be shared-nothing and fault tolerant
MySQL replication will normally detect problems and reconnect anyway, continuing from where it left off.
If you're getting replication errors, it's likely that the source is something else. MySQL replication effectively does a "tail -f" on the query log and replays it on the slave (it's slightly smarter than that, but not much).
If the databases become out of sync, MySQL replication will neither detect nor repair this, but it may eventually cause it to break as a subsequent update cannot proceed due to conflicting data on the slave.
The default timeouts on the replication slave are much too long - it waits hours (or something) - you'll want to reduce this.
Data becoming out of sync is difficult to avoid, mitigation steps are:
Monitor replication using something like mk-table-checksum from Maatkit
Audit all your code for replication-unsafe queries
If using 5.1, switch to row-based replication, which is less likely to suffer from this problem