I am trying to replicate my two instance of mysql databases located in different location.
Till now I am successful in replicating the databases. But suppose when one server is temporarily down, it stops sending its data to slave whereas another keeps on sending its data. This creates two different sets of database instances.
Is it possible to replicate the data from where it has been stopped.
This is my setup for replication:
Server 1:
server-id = 1
replicate-same-server-id=0
auto-increment-increment=2
auto-increment-offset=1
mysql> CHANGE MASTER TO MASTER_HOST='192.168.x.x', MASTER_USER='abcd', MASTER_PASSWORD='password', MASTER_LOG_FILE="mysql-bin.000003", MASTER_LOG_POS=98;
Server 2:
server-id = 2
replicate-same-server-id=0
auto-increment-increment=2
auto-increment-offset=2
mysql> CHANGE MASTER TO MASTER_HOST='192.168.x.x', MASTER_USER='abcde', MASTER_PASSWORD='password', MASTER_LOG_FILE="mysql-bin.000004", MASTER_LOG_POS=198;
Is there any way to continue the replication from where it has been stopped.
try 'stop slave; reset slave; start slave;'
I also encounter the issue. After I change to ROW mode, the issue is gone.
[mysqld]
server-id=1
log_bin=mysql-bin
binlog_format=ROW
Related
i have issue to set different replication_do_db replication in each channel.
so i want to set like this : replicate_do_db=db1 for channel a and replicate_do_db=db2 for channel b
as far i know we can use CHANGE REPLICATION FILTER REPLICATE_DO_DB = (d1) FOR CHANNEL channel_1 in mysql 8.
but how if we use in mysql 5.7?
any solution?
Looks like you have one master and multiple slaves, each one intended for a different database.
You can replicate each database on master to a different slave by specifying this in slave my.cnf
Slave1 (channel_1)
[mysqld]
replicate-do-db=channel_1
Slave2 (channel_2)
[mysqld]
replicate-do-db=channel_2
And so on.
Note that each slave will still get ALL binary logs relayed (i.e. each database entire data) but selectively apply them in the slave server as per the database specified in the my.cnf.
This is an afterthought in case your question is about how to specify multiple databases in a replicate-do-db option, you can do so comma separated -
[mysqld]
replicate-do-db=channel_1,channel_2
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
I have two mySQL databases set up as master-slave. Do I need to issue a command to the master to stop this replication?
From previous posts I understand that I have to issue the following commands to slave:
stop slave
reset slave
And add skip-slave-start to my.cnf
This question :
https://stackoverflow.com/questions/91814/how-do-i-completely-disable-mysql-replication
Addresses master-master. I'd like a similar answer for master-slave config please. Thanks in advance!
Till bin-log is enabled on master and server-id is set, it can be a master to any slave as I know. You can set server-id of master to 0 for disabling replication from master side.
Check article on mysql dev
If you only want to stop replication from the master to the slave, you don't have to do anything on the master. The master can chug along happily.
Though you should note that the master will still have binary log going, but you'll probably want that. : )
I'm looking for a way to have 2 databases running; 1 at the office and 1 at a data center. When at the office, employees would connect locally but when outside the office they would connect remotely to the data center. Both databases would be fully synchronized. That means that an employee could log in and update a record on the data center and that change would replicate instantly to the office server (or vice-versa). So, either user could edit the same record.
So, the typical scenario of auto_increment_offset etc. won't work because, in this case, each server has to be able to update the same record.
Am I missing something obvious? I can't think of a viable way to handle this. 2 users on 1 db can modify the same records so there HAS to be a way to do the same in this type of setup. I just can't think of one.
You can not do this reliably with asynchronous replication. Consider this simple example:
site A: update foo set bar = 1
site B: update foo set bar = 2
Some time later (milliseconds or hours depending) the transactions are replicated to each site:
site A: update foo set bar = 2
site B: update foo set bar = 1
foo.bar will now be 2 on site A and 1 on site B. There is nothing in MySQL that will detect this or prevent it from happening.
Either partition the problem so the masters "own" different parts of the data or elect a primary master for all updates. Or implement some global locking mechanism.
With one database things are completely different since there is synchronous locking going on internally.
Here's how we did it:
In master-master configuration there are 2 masters and 2 slaves. Both are masters and slaves at the same time:
master1 => slave1[master2]
[slave1]master1 <= slave2
enable binlogging on master server - my.cnf file under [mysqld] section:
log-bin=mysql-bin.log
relay_log=relay-bin.log
server-id = 1
log-slave-updates
auto_increment_increment = 10
auto_increment_offset = 1
You may need to add:
skip-slave-start option too, to prevent from start slave at database startup.
Note:
Each server should use different server-id
auto_increment_offset should differs
Auto increment options:
auto_increment_increment controls the increment between successive AUTO_INCREMENT values.
auto_increment_offset determines the starting point for AUTO_INCREMENT column values.
With auto_increment_increment = 10 and auto_increment_offset=5, auto_inc values would be 5, 15, 25..
Dedicated user:
GRANT REPLICATION SLAVE ON . TO 'replication'#'%' IDENTIFIED BY 'some_password';
Create consistent, binary backup of MySQL database (needed to setup a replication) using LVM but the same steps will apply to ZFS/UFS snapshot and other popular techniques:
connect to MySQL database on master (server1) and run "FLUSH TABLES WITH READ LOCK". It might take few second to complete flush operation and it will lock all tables! It is imporant to keep it in mind, because such operation may impact in production load in some cases. It's better to schedule replication setup to peak-off hours.
Create LVM snapshot (server1): lvcreate -L10G -s -n mysqlbackup /dev/vg/lvm_mysql_partition
Get information about master position. Using previously created connection to database run : SHOW MASTER STATUS; to get all information about current binlog, position and so on.
Copy-paste output somewhere - for future usage.
Uunlock all tables: UNLOCK TABLES;
Mount previously created filesystem: mount /dev/vg/mysqlbackup (this will allow you to access shapshot of data created).
Now you can just copy this data to the second server directly to data dir. Before you start up your database add previously mentioned parameters to my.cnf file, changing value of server-id.
Now, with master information copied somewhere and database files propagated to slave you can remove snapshot: lvremove -f /dev/vg/mysqlbackup on master (server1).
Now, you can log into server2 to check for permissions (depends on which user was used to copy files you'll need to correct it) and after that, startup MySQL instance. Database should start, perform InnoDB recovery (if you're signed it) and after a bit, you will be able to log into using command line client. Because of skip-slave-start your slave will not start by default.
Now, on both servers you need to configure replication thread by setting up master hostname, master port, password, user and info about position:
CHANGE MASTER TO master_host='IP_addr_of_server1', master_port=3306, master_user='replication', master_password='some_password', master_log_file='info_from_MASTER_STATUS', master_log_pos='info_from_MASTER_STATUS';
Now you can start replication: START SLAVE;
Check to make sure: SHOW SLAVE STATUS\G (on new machine)
Seconds_Behind_Master might not be equal to 0 because of changes done to database after you release all tables but with replication working slave should catch master pretty fast.
After your slave server catches up with master, start master-master (server1-server2) setup. Lock all tables on server2 ( FLUSH TABLES WITH READ LOCK;) and run SHOW MASTER STATUS;. On server1 set-up replication by CHANGE MASTER TO..
of course you need to change master_host to valid IP address, master_log_file and master_log_pos values. After that, UNLOCK TABLES on server2 and START SLAVE on server1.
Now you should have master-master-slave configuration with master-master replication between server1 and server2.
I have an existing mysql replication set up (Windows 2008 to Ubuntu 9.04) and created several new tables in the master database. These are not showing up in the slave database.
Do new tables automatically get copied to the slave DB, or do I need to set up replication again?
Thanks!
I'm going to assume that other data is successfully replicating.
Replication in mysql is per-server, so the most likely problems are that either you aren't binloging the events, or that the slave is ignoring them.
For binglogs, verify you aren't turning sql_log_bin off for the connection (which would require SUPER) and that the various options binary-log options are set correctly. You can verify this by running mysqlbinlog on the server's binlogs.
On the slave side, check the replication options.