MySQL Master-Slave Replication When Master is Down - mysql

I'm running MySQL as the database on Ubuntu instances. I'm using MySQL Master-Slave replication where master's changes will be written to slave and slave's changes will not be reflected on the master. That's fine. I'm using a HAProxy load balancer to front the MySQL instances where all the requests will be sent to master MySQL instance. If the master MySQL instance is down slave MySQL instance will act as master and HAProxy will send all the requests to salve. Active-Passive scenario.
HAProxy - 192.168.A.ABC
MySQL Master - 192.168.A.ABD
MySQL Slave - 192.168.A.ABE
Let's assume that the MySQL master(192.168.A.ABD) is down. Now all the requests will be sent to MySQL slave(192.168.A.ABE) by HAProxy where now he acts as the master MySQL server for the time being.
My problems are
What happens when original master MySQL instance(192.168.A.ABD) is up?
Will changes written to new MySQL master (192.168.A.ABE) be replicated to original master(192.168.A.ABD) again?
How should I address this scenario?

First of all I should say that I have never used HA Proxy so con't comment on that directly.
However, in your current setup the Master (ABD) will be out of sync, and wont catch up. You will have to rebuild that using mysqlDump or similar tool.
What you would need is a Master < > Master setup (as opposed to Master > Slave), which enables you to write to either database and have it reflected in the other. This isn't quite as straight forward as it sounds though.
Assuming you already have your master > slave setup, and they are in sync
On the Master (ABD) you want to add:
auto_increment_increment=2
auto_increment_offset=1
log-slave-updates
On the Slave (ABE) add:
auto_increment_increment=2
auto_increment_offset=2
log-slave-updates
to your my.cnf files. Restart the Database. This will help to prevent Duplicate Key Errors. (n.b. that log-slave-updates isn't strictly required but makes it easier to add another slave in future)
Next you want to tell the Master (ABD) to replicate from the Slave (ABE).
Depending on what version of MySQL and if you are using GTID etc. the exact process differs slightly. But basically you are going to issue a CHANGE MASTER statement on the Master so it replicates from the slave.
And away you go. You probably want to avoid writing to both at the same time as that opens up a whole other kettle of fish. But if the Master goes down, you can switch your writes to the slave, and when the master comes back up, it will simply start replicating the missing data.

I am considering you scenario
Master - 192.168.A.ABD
Slave - 192.168.A.ABE
You cannot directly add the master in system. To Add master in system you need to perform below steps:
1) When master is up you can add this as a slave. So now this happens
Master - 192.168.A.ABE
Slave - 192.168.A.ABD
2) Then Now U can put master Down. Means You can put 192.168.A.ABD Down
3) Then Again Add this as slave. So After this You will get below scenarion
Master - 192.168.A.ABD
Slave - 192.168.A.ABE
You can refer this link
https://dev.mysql.com/doc/refman/5.5/en/replication-solutions-switch.html

Related

How to setup Active/Passive HAproxy configuration for MySQL with automatic failover but not automatic failback

I want to set Master - Master replication in MySQL using HAproxy as Load Balancer.
Using backup option for Master 2 helps to route traffic to Master 2 only when Master 1 is down, but as soon as Master 1 comes up, traffic is automatically routed to Master 1; it does not wait for the replication to complete. Need help on the configuration.
Found a link as below but not sure on how to set the peers and will it be helpful for MySQL. Looking for a working solution.
https://www.haproxy.com/blog/emulating-activepassing-application-clustering-with-haproxy/
You should consider running keepalived service on two masters. keepalived enables virtualIP that can be bound to active master. post failover of the primary master, the virtualIP gets bound to standby master and would become primary.
when old primary comes backup, it would become standby and the failback doesnt happen.

Slave isn't writing any data into the table in mysql master slave replication

I am having a difficult time in setting Master-Slave configuration.
Master Database runs on Ubuntu( Amazon AWS instance) and successfully set-up master replication.
I have localhost as a Slave Server. (Windows Machine).
Snapshot of Master Database
Master database has record
Binar Log Information
Process List on Master Replication
Status of Master Replication
I debug master replication which works okay I guess.
On the Salve Side:
Status on Slave Side
Even though MASTER_LOG and MASTER_POS are synced but data doesn't.
Currently, I have 0 table on Slave side and 34 tables on Master side.
Tables on Slave side
I am open to any suggestion or any reference do you have.
I spend an entire day and trying to find what I did wrong.
I want to Sync my Local database with a database hosted on remote-server.
Update: Thigs I did to debug the Master-Slave Replication
Checked Master Database is up and running.
Master Status and Connected Slaves. [Which includes unique id for
each server.]
Slave database is up and running [Including Slave IO Thread and
SQL thread is running.]
These three steps ensure that Master-Slave replication is up and running without any problem.
Handling Data Sync Problem
Created/update/delete data in the master database to check
whether data is sync on a server or not.
Checked Binary Log [Specifically I checked the file size. If I
entered data file size will continuously increasing.]
Thanks in advance.
we had similar problem - read more about gotchas in "binlog-do-db" and "replication-do-db" and related parameters. Here is a big problem with crossdatabase references. At the and we had to remove these settings limiting replication.
Why MySQL’s binlog-do-db option is dangerous
Gotchas in MySQL replication
As your show slave status output says you enabled Replicate_DO_DB for the DB "Arihantpos" at the same time you did Binglog_Do_Db for the same db
try to remove Binglog_Do_Db from config file and restart mysql and start replication again

mariaDB(mysql) replication after slave is up after down

I have remote host (centos6) with mariadb (10.0.17-MariaDB-log - MariaDB Server) as master:
server-id = 1
log-bin=mysql-bin
binlog_do_db = mydatabase
and local (win8.1) with mariadb (10.0.16-MariaDB-log - mariadb.org binary distribution) as a slave:
server-id = 2
As initial procedure I've dumped database on remote host, imported it on local host, then executed SHOW MASTER STATUS, get filename and offset and run:
CHANGE MASTER TO MASTER_HOST='$host', MASTER_USER='$user', MASTER_PORT = $port, MASTER_PASSWORD='$pass', MASTER_LOG_FILE='$fname', MASTER_LOG_POS=$pos
STOP SLAVE
START SLAVE
Replication starts. Everything I do with table on master is reflected to slave.
But if slave goes down, after it is up no changes (made on master) while slave was offline reflected to slave! So it looks like my slave should always be online, but it's a laptop!
However after slave is up realtime replication still works - it doesn't remember all changes from offline, but if I change database on master when slave is online and started all changes are perfectly reflected to slave. Of course I know that replication is statement based, so I get not data diff but instructions. But I thought master remembers what it sent and what did not. So on next operation it just sends all non-delivered changes. Am I wrong?
My replication scenario: master server interacts with clients (mobile devices) and they change the database. From time to time I launch my laptop, start replication, get updated database and do some heavy analysis (it's too hard for my 2-core cheap server).
Maybe there is a better method? Is there a way to get "offline changes" like in ICQ messenger? :)
For now I can see only one solution - full db dump, but it is inconvenient, takes too much time and loads master heavily.
While the Slave is not connected to the Master, the Master is writing to its binlog(s). The Slave has remembered where it left off in reading from those binlogs. When the Slave reconnects, it picks up "where it left off", copies the changes from the Master's binlog(s) to the Slaves relay-log(s) and performs them. This "catchup" process will take a little time, how long depends on a lot of factors.
Do SHOW SLAVE STATUS; on the Slave to verify that it is connected and running ("Yes").
Normally, the version of the Slave should be no older than that of the Master. (I doubt if there is any issue between 10.0.17 vs 16. Nothing in the changelog for 10.0.17 jumps out at me.)
Are you using "parallel replication"? See bug fixed in 10.0.18.

about mysql high-availability

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.

writes to mysql slave server by mistake

I have mysql replication set up with one master and one slave. Due to a bug in the code, somewhere in the middle the entries started to get written on slave server and it was detected a few days later on.
Now I am thinking of how to switch it correctly without any hassle or minimal down time, what would be the best way to do this? Lets consider only one table...
Solution 1
Simply start writing to master from now on after setting auto_increment to slave's last id. Wondering if it will be troublesome to keep master and slave out of sync.
Solution 2
Clear all the data from master, stop the app from making any more entries refill the data using mysqldump and then switching the app back on with correct config.
stop slave
// load the dump
start slave
Will this stop master from re-attempting to write to slave the same data?
Any help appreciated. Any other solutions also welcomed.
Thanks
Sushil
I think you are on the correct track with solution 2. Simply stopping the slave will not prevent the master from writing to it's binary log. So when you start the slave again it will just replicate all the SQL statements from the master.
However, you can use this to your advantage if you have included 'DROP TABLE' before each table creation. This will mean that you have the following:
1) Stop the app from making any more entries in the master table(s)
2) Dump data from slave (ensure that mysqldump includes 'DROP TABLE' before each table import - it should do as it is a default option of mysqldump)
3) Run dump against master
4) Check slave status using SHOW SLAVE STATUS\G. Once Seconds_Behind_Master reaches 0 then you are good to switch on the app again (make sure it is writing to the master!!)
Step 3 will drop and recreate the tables on the master using the data from the slave. This drop and recreate will be replicated on to the slave so you should end up with the two in sync and a correct master slave set up.
Good luck!
I think your best option is to reset the slave/master completely. If the data on the slave is correct reload the data from it and then export export a new dump from the master and import it to the slave, then execute a new "CHANGE MASTER TO..." command
I would recommend setting the "read_only" global variable on the slave.
http://dev.mysql.com/doc/refman/5.1/en/replication-options-slave.html#option_mysqld_read-only