Can anyone please help me out for the master slave replication in Windows(Step by step).I have googled it but there is no proper configuration(my.ini) found for windows ,its always for LINUX. Any help will be appreciated
Step 1 ) on master
stop server on master,
set server-id =1,
enable log-bin=mysql-bin in my.ini,
start mysql server
2) on slave
stop mysql server,
set server-id =2 in my.ini
start mysql server
3) on master
create replication user on master with slave IP like below
CREATE USER 'repli_user'#'slave_IP' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repli_user'#'slave_IP';
4) Go To Master
flush tables with read lock;
show master status;
(note offset file number and offset position)
unlock tables;
5) On slave
change master to
master_host = 'master_IP',
master_user = 'repli_user',
master_password= 'password',
master_log_file = 'mysql-bin.<file-number>',
master_log_pos = offset-pos;
6)
on slave
start slave;
show slave status;
You should get "Waiting for master to send event" as slave status;
Related
MySQL Replication VS Mirroring and how to do both, does anyone knows some information on this topic?
MySQL Replication: https://www.youtube.com/watch?v=APAmsHAYUiI
So replication it is one way relationship: Master to Slave.
Mysql:
Stop Slave: stop slave;
Tell the Slave that it is a Slave and where to locate the Master:
Mysql:
CHANGE MASTER TO
MASTER_HOST = '192.168.1.111',
MASTER_USER = 'master_replication_user',
MASTER_PASSWORD = 'master_password',
MASTER_LOG_FILE = 'DESKTOP-MASTER-PC-bin.000978',
MASTER_LOG_POS = 678;
Start Slave: start slave;
Check Slave Status: show slave status;
MySQL Mirroring: https://www.ryadel.com/en/mysql-master-master-replication-setup-in-5-easy-steps/
The main point here is: There are two Masters (so they like a slave to each other, but they will never admit it). You just tell Master A that it is slave of the Master B. And then you tell Master B that he is the slave of Master A. It is reciprocal relationship.
Stop Master A: stop slave;
Stop Master B: stop slave;
3.Tell the Master A where to locate the Master B
CHANGE MASTER TO
MASTER_HOST = '192.168.1.111',
MASTER_USER = 'master_b_replication_user',
MASTER_PASSWORD = 'master_b_password',
MASTER_LOG_FILE = 'DESKTOP-MASTER-B-PC-bin.000756',
MASTER_LOG_POS = 888;
4.Tell the Second Master where to locate the First Master
CHANGE MASTER TO
MASTER_HOST = '192.168.1.112',
MASTER_USER = 'master_a_replication_user',
MASTER_PASSWORD = 'master_a_password',
MASTER_LOG_FILE = 'DESKTOP-MASTER-A-PC-bin.000001',
MASTER_LOG_POS = 777;
Mysql:
5.Master A: start slave;
6.Master B: start slave;
7.Check Master A Status: show slave status;
8.Check Master B Status: show slave status;
We are new to MySQL 5.7. Currently, we are using MySQL 5.5.
Now we want to enable multi-source replication by using MySQL 5.7.
To do this initially, we upgraded to 5.6 and then 5.7 but are stuck on how to set-up MySQL GTID replication.
Can any one will help me in suggesting set-up process for setting replication?
Thanks in advance.
Step 1 ) on master
stop mysql server on master,
set server-id =1
enable log-bin=mysql-bin in my.ini, start mysql server
2) on slave
stop mysql server,
set server-id =2 in my.ini
start mysql server
3) on master create replication user on master with slave IP like below
CREATE USER 'repli_user'#'slave_IP' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repli_user'#'slave_IP';
4) Go To Master
flush tables with read lock;
show master status;
(note offset file number and offset position)
unlock tables;
5) On slave
change master to
master_host = 'master_IP',
master_user = 'repli_user',
master_password= 'password',
master_log_file = 'mysql-bin.<file-number>',
master_log_pos = offset-pos;
6) on slave
start slave;
show slave status;
You should get "Waiting for master to send event" as slave status;
I want to create a replica to my Percona Server with GTID enabled, but got this error when i show slave status:
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
Normally, i would stop my slave, reset it, reset master (on the slave), and get new GTID_PURGED value from the master. But this time around, the master has a very unusual value(s) and i am not sure how to determine which one to use:
mysql> show master status\G
*************************** 1. row ***************************
File: mysqld-bin.000283
Position: 316137263
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set: 1570dee1-165b-11e6-a4a2-00e081e93212:1-3537,
c73f3ee7-e8d4-ee19-6507-f898a9930ccd:1-18609,
cdb70eaa-f753-ee1b-5c95-ecb8024ae729:1-2357789559:2357789561-2357790104:2357790106-2514115701:2514115703-2514115705:2514115707-2546512667
1 row in set (0.00 sec)
From the slave with the new backup copy, i get this:
root#ubuntu:/var/lib/mysql# cat xtrabackup_binlog_info
mysqld-bin.000283 294922064 1570dee1-165b-11e6-a4a2-00e081e93212:1-3537,
c73f3ee7-e8d4-ee19-6507-f898a9930ccd:1-18609,
cdb70eaa-f753-ee1b-5c95-ecb8024ae729:1-2357789559:2357789561-2357790104:2357790106-2514115701:2514115703-2514115705:2514115707-2546400960
One more thing, i just purged the binary logs on the master before i made a backup. automatic binlog purge is set to 7 days. So i know its not because the bin log has been purged as the error is suggesting.
I am running Ubuntu 14:04, and Percona server version 5.6.31-77.
How can i resolve this issue? What is the correct value of the master's GTID_PURGED?
mysql 5.6 GTID replication errors and fixes
What is GTID? 
4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4
This is the server's 128 bit identification number (SERVER_UUID). It identifies where the transaction was originated. Every server has its own SERVER_UUID.
What problems GTID solves?
It is possible to identify a transaction uniquely across the replication servers. Make the automation of failover process much easier. There is no need to do calculations, inspect the binary log and so on. Just MASTER_AUTO_POSITION=1.
At application level, it is easier to do WRITE/READ split. After a write on the MASTER, you have a GTID so just check if that GTID has been executed on the SLAVE that you use for reads.
Development of new automation tools isn't a pain now.
How can I implement it?
Three variables are needed in ALL servers of the replication chain
gtid_mode: It can be ON or OFF (not 1 or 0). It enables the GTID on the server.
log_bin: Enable binary logs. Mandatory to create a replication environment.
log-slave-updates: Slave servers must log the changes that come from the master in its own binary log.
enforce-gtid-consistency: Statements that can't be logged in a transactionally safe manner are denied by the server.
ref: http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-howto.html
Replication errors and fixes:
"'Got fatal error 1236 from master when reading data from binary log: "The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires." slave_io thread stop running.
Resolution: Considering following are the master – slave UUID's
MASTER UUID: 4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4
SLAVE UUID: 5b37def1-6189-11e3-bee0-e89a8f22a444
Steps:
slave>stop slave;
slave> FLUSH TABLES WITH READ LOCK;
slave>show master status;
'4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4:1-83345127,5b37def1-6189-11e3-bee0-e89a8f22a444:1-13030:13032-13317:13322-13325:13328-653183:653185-654126:654128-1400817:1400820-3423394:3423401-5779965′
(HERE 83345127 Last GTID executed on master and 5779965 Last slave GTID executed on Master )
slave> reset master;
slave>set global GTID_PURGED='4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4:1-83345127,5b37def1-6189-11e3-bee0-e89a8f22a444:1-5779965′;
slave>start slave;
slave>unlock tables;
slave>show slave status;
NOTE: After this Re-start slave other chain-slaves if they stop replicating;
ERROR: 'Error "Table … 'doesn"t exist" on query. Default database: …Query: "INSERT INTO OR Last_SQL_Error: ….Error 'Duplicate entry' SKIP Transaction on slave (slave_sql Thread stop running) NOTE:
SQL_SLAVE_SKIP_COUNTER doesn't work anymore with GTID.
We need to find what transaction is causing the replication to fail.
– From binary log
– From SHOW SLAVE STATUS (retrieved vs executed)
Type of errors: (check last sql error in show slave status)
Resolution: Considering following are the master – slave UUID's
MASTER UUID: 4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4
SLAVE UUID: 5b37def1-6189-11e3-bee0-e89a8f22a444
slave>show slave status;
copy the 'Executed_Gtid_Set' value. '4c2ad77f-697e-11e3-b2c3-c80aa9f17dc4:1-659731804,5b37def1-6189-11e3-bee0-e89a8f22a444:1-70734947-80436012:80436021-80437839'
-Seems that slave (with uuid 5b37def1-6189-11e3-bee0-e89a8f22a444) transaction '80437840' is causing the problem here.
slave> STOP SLAVE;
slave> SET GTID_NEXT="5b37def1-6189-11e3-bee0-e89a8f22a444:80437840"; (last_executed_slave_gtid_on_master + 1)
slave> BEGIN; COMMIT;
slave> SET GTID_NEXT="AUTOMATIC";
slave> START SLAVE;
slave> show slave status;
and it's ALL SET !!!
#If using xtrabackup is the backup in the main instance.
cat xtrabackup_info | grep binlog_pos
#Use the information you gave as an example：
binlog_pos = filename 'mysqld-bin.000283', position '294922064', GTID of the last change '1570dee1-165b-11e6-a4a2-00e081e93212:1-3537,c73f3ee7-e8d4-ee19-6507-f898a9930ccd:1-18609,cdb70eaa-f753-ee1b-5c95-ecb8024ae729:1-2357789559:2357789561-2357790104:2357790106-2514115701:2514115703-2514115705:2514115707-2546400960'
#copy GTID of the last change to gtid_purged
slave>STOP SLAVE;
slave>RESET MASTER;
slave>SET GLOBAL gtid_purged='1570dee1-165b-11e6-a4a2-00e081e93212:1-3537,c73f3ee7-e8d4-ee19-6507-f898a9930ccd:1-18609,cdb70eaa-f753-ee1b-5c95-ecb8024ae729:1-2357789559:2357789561-2357790104:2357790106-2514115701:2514115703-2514115705:2514115707-2546400960';
slave>change master to master_host='master ip',master_port=master port,MASTER_USER = 'Your replicate username', MASTER_PASSWORD = 'Your replicate password',master_auto_position=1;
slave>START SLAVE;
Master db MySQL db Server 2012
Slave db MySQL Win7 XAMPP
DB size 500MB
Table count 42
I have setup the replication successfully however it stopped last week and my slave was showing the error Slave_SQL_Running No. I realised that it was looking at an incorrect log file (00004 whereas it should have been 00006).
I have since sorted this by;
At the MASTER;
SHOW MASTER STATUS;
Copied the values of MASTER_LOG_FILE and MASTER_LOG_POS.
At the SLAVE;
STOP SLAVE;
RESET SLAVE;
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=98; (<- example values)
START SLAVE;
SHOW SLAVE STATUS \G;
On my master I tested the replication by editing the table members - I edited one of the row values (from 85 to 86 - this successfully replicated in my slave). However I notice that on my master members table there are 70652 members but on my slave there are only 70056.
I added two new members to my master members table and the total increases by 2 on both tables. However there still seems to be that 600 missing?
What could be the problem? Replication seems to be working but totals aren't. New members are added to the members table each day, but the aren't being added to my slave members table.
The results of my slave status table (from phpmyadmin) are;
Slave_IO_State Waiting for master to send event
Master_Host xxx.xxx.xxx.xxx
Master_User repl
Master_Port 3306
Connect_Retry 60
Master_Log_File mysql-bin.000006
Read_Master_Log_Pos 787956776
Relay_Log_File mysql-relay-bin.000004
Relay_Log_Pos 624412
Relay_Master_Log_File mysql-bin.000006
Slave_IO_Running Yes
Slave_SQL_Running Yes
Replicate_Do_DB
Replicate_Ignore_DB
Replicate_Do_Table
Replicate_Ignore_Table
Replicate_Wild_Do_Table
Replicate_Wild_Ignore_Table
Last_Errno 0
Last_Error
Skip_Counter 0
Exec_Master_Log_Pos 787956776
Relay_Log_Space 788197
Until_Condition None
Until_Log_File
Until_Log_Pos 0
Master_SSL_Allowed No
Master_SSL_CA_File
Master_SSL_CA_Path
Master_SSL_Cert
Master_SSL_Cipher
Master_SSL_Key
Seconds_Behind_Master 0
Is there something else that I could check or test?
Yes, when you stopped the replication was some rows changed or inserted. After this you have RESET the SLAVE and set the MASTER_LOG_POS. So the replication NEVER can gets the old changes.
You have 2 Options:
First:
Stop Replication
Dump the Master DB (with master position)
Restore it in the Slave
set set Position or check them
start slave
second
Stop slave
sync the masterDB to Slave DB with percona Toolkit - pt-table-sync
Start slave
I have a web app with 2 web servers and 2 database servers. The dbs are setup for multi master replication. (this is the primary environment)
I also have the exact same setup on a different location acting as standby, in case the primary env fails. (this is the backup env)
What I need is for the backup env to be in sync with the dbs of the primary site. However, all dbs in both environments have already replication configured.
How can I achieve my goal?
Thanks
If this is standard MySQL rather than MySQL Cluster (and from your setup I think is has to be), you can't AFAIK.
If you have hierarchical replication then you could make it work, but with multimaster you can't. The basic problem is that a slave can only have one master which is set by the CHANGE MASTER TO command.
MySQL Cluster operates in a more complex manner, you have several servers in each cluster and then the cluster can be replicated to another cluster... or something.
Not very helpful I'm afraid.
You can sync the backup servers to one of the other masters, but the backup servers would not be masters to each other until you have a problem and then you change the master slave relationships yourself.
1 Configure The Master
First we have to edit /etc/mysql/my.cnf. or /etc/my.cnf We have to enable networking for MySQL, and MySQL should listen on all IP addresses, therefore we comment out these lines (if existant):
#skip-networking
skip-external-locking
bind-address=0.0.0.0
log-bin=mysql-bin.log
binlog-do-db=exampledb (database name)
server-id=1
Then we restart MySQL:
/etc/init.d/mysql restart
Create a user with replication privileges
GRANT REPLICATION SLAVE ON *.* TO 'slave_user'#'%' IDENTIFIED BY '<some_password>'; (Replace <some_password> with a real password!)
FLUSH PRIVILEGES;
Take dump of database(exampledb) and run command
SHOW MASTER STATUS
It will give you result like
---------------+----------+--------------+------------------+
| File | Position | Binlog_do_db | Binlog_ignore_db |
+---------------+----------+--------------+------------------+
| mysql-bin.006 | 183 | database name| |
+---------------+----------+--------------+------------------+
1 row in set (0.00 sec
Write down this information, we will need it later on the slave!
Then leave the MySQL shell:
quit;
2 Configure The Slave
On the slave we first have to create the sample database exampledb:
mysql -u root -p
Enter password:
CREATE DATABASE exampledb;
quit;
store databse dump on slave
Now we have to tell MySQL on the slave that it is the slave, that the master is 192.168.0.100, and that the master database to watch is exampledb. Therefore we add the following lines to /etc/mysql/my.cnf or /etc/my.cnf if file doesnot exists copy from other location
server-id=2
master-host=192.168.0.100(ip address of master host machine)
master-user=slave_user(user name)
master-password=secret (password)
master-connect-retry=60
replicate-do-db=exampledb (database name)
Then we restart MySQL:
/etc/init.d/mysql restart
Finally, we must do this:
mysql -u root -p
Enter password:
SLAVE STOP;
In the next command (still on the MySQL shell) you have to replace the values appropriately:
CHANGE MASTER TO MASTER_HOST=’master ip address’, MASTER_USER='slave_user', MASTER_PASSWORD='<some_password>', MASTER_LOG_FILE='mysql-bin.006', MASTER_LOG_POS=183;
MASTER_HOST is the IP address or hostname of the master (in this example it is 192.168.0.100).
MASTER_USER is the user we granted replication privileges on the master.
MASTER_PASSWORD is the password of MASTER_USER on the master.
MASTER_LOG_FILE is the file MySQL gave back when you ran SHOW MASTER STATUS; on the master.
MASTER_LOG_POS is the position MySQL gave back when you ran SHOW MASTER STATUS; on the master.
Now all that is left to do is start the slave. Still on the MySQL shell we run
START SLAVE;
quit;
That's it! Now whenever exampledb is updated on the master, all changes will be replicated to exampledb on the slave. Test it!