I have a redis master setup with 2 slaves and a sentinal on each.
If the master goes down for say 2 seconds (+sdown) and comes back up (-sdown), it reads the last snapshot, and the slaves resync with the master.
The problem with this is that there may have been many writes between the last save and the +sdown. It seems like if the master goes from +sdown to -sdown and never +odown (where a failover is initiated), it should be able to sync FROM a slave. My reasoning is that the replication stream is continuous and the slaves most likely have a more accurate reflection of the masters state when +sdown happened.
Is there some config that I can do this? Am I forced to rely on the AOF or snapshots?
(Edit: adding sentinel tag)
You cannot do a partial failover, either you do it or you don't in terms of promoting the slave to master.
From Redis Sentinel:
Automatic failover. If a master is not working as expected, Sentinel can start a failover process where a slave is promoted to master, the other additional slaves are reconfigured to use the new master, and the applications using the Redis server informed about the new address to use when connecting.
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.
I'm mysql newbie.
when it comes to fail-over, which slave should be promoted to the new master?
For example, A is master, B and C are slaves, and A does async replication to B and C.
At some point of time, B receives more data from A than C, A crashes.
If we promote C to new master, and changes B's master to C, then what happens to B? It truncates its data to match C?
Obviously, B is the best new master candidate, but my question is, how to determine this fact?
From the MySQL documentation, there two ways to set up a master-slave architecture. The traditional way, using the log files to replicate transactions and the new version (5.6+) using GTIDs (global transaction identifiers).
If you choose to use GTIDs to make the failover handling you will use the mysqlfailover utility. The utility handles fails of master in one of three ways defined by the database administrator:
auto (default): A search is made in a list of prefered slaves to become master, if none are available another slave is chosen. The chosen slave first becomes the slave to all others slaves and has all the changes from the other slaves copied to it, this way the new master will be the most up to date version possible.
elect: the same as above, except that if no slaves from the list are available it returns an error and finishes (no failover)
fail: No failover happens mysqlfailover will just monitor the database and return an error if a fail happens.
The traditional way requires that you implement your own script to database management and is better explained here.
The Relay_Master_Log_File and Exec_Master_Log_Pos in SHOW SLAVE STATUS is used to determine the best slave as new master: the bigger values win.
Without GTID, I think we must first sync other slaves with the best slave we chose. The obvious sync source is the relay logs. On each slave, determine the differences of relay log from the best slave, download those files and replay the SQL statements. Once all slaves catch up, the slaves could CHANGE MASTER TO the best slave. The MASTER_LOG_FILE and MASTER_LOG_POS would be the tail of the last binlog on the best slave.
With GTID, it's very simple: just CHANGE MASTER TO with MASTER_AUTO_POSITION=1.
I recently had a RDS read replica crash, so needed to spin up a new read replica.
Now I have both read replicas there.
I want to delete the one that failed.
Is it just a case of terminating it? Does it have any affect on the master or the other read replica?
Have not ever had to do this before, so want to be sure I am doing this the right way
This should be a perfectly safe operation, but taking a last-minute snapshot of your master (or even the other replica, if it's on-line, replicating, and synched) wouldn't hurt.
In MySQL replication, the connection between master and replica is initiated from the replica ("slave") server side -- if a replica goes offline, the master server just closes the connection and goes about its business; there is essentially no risk to the master from a replica disappearing, even at random.
Specifically, in RDS, replicas seem fairly clearly to be designed to be disposable, and RDS also provides the ability to "promote" a replica -- which is not a promotion to being "the" master (replacing the existing one), but rather a promotion to being "a" master, an independent standalone system of its own, fully disconnected from its former relationship with its former master.
If it made you more comfortable, you could "promote" the replica first, and then delete it once you see that process complete, though simply deleting the replica should be harmless.
http://aws.amazon.com/about-aws/whats-new/2012/10/11/amazon-rds-mysql-rr-promotion/
For my application I will have one master db with one slave db, the slave will be used for me to run my backups on without interrupting my application. However I have seen examples with one master with multiple slaves and I am wondering why and if my application would benefit from having more than one slave that I have not thought of.
So put simply, what could be the reasons for having more than one slave?
Multiple slaves allows you to distribute your reads. If you have a read heavy application, you can scale it with multiple slave servers. It also offers a layer of fault tolerance - if your master dies, you can promote one of the slaves to be the master.
I have configured a MySql Replication with 1 Master 1 Standy and 1 Slave. Master and Standby are put on different availability zones on US East region and the Slave is on the US West region. Both Standby and Slave are replicating from the Master.
The Application layer can do the failover from Master to the Standby.For switching the replication of the Slave to the Standby when the Master dies. I have no way to assure that the Standby's data is ahead comparing to the Slave's data. If Standby's data is behind the Slave's data I need to scan the Slave's binary and relay logs to find out what is missing and transfer it the Standby. That's the THEORY.
Does anyone know any tool which can handle this ? or alternative solution for my context ?
The ultimate goal is the availability of MySql Server for application layer. I have tried MySql-Proxy but not quite happy with it. Mysql Cluster is not an option for us.
Thanks in advanced.
Kane,
Take a look at SchoonerSQL from Schooner Information Technology (my company). It is designed to have zero slave lag locally through multi-threaded synchronous replication (in current release) and automatic fail-over across regions through multi-threaded Asynchronous WAN replication (to be released in < 2 wks). http://www.schoonerinfotech.com/products/schoonersql