I'm testing MySQL replication on two virtual machines with VirtualBox running Debian 8.2.
Following tutorials, this is how I set the slave's /etc/mysql/my.cnf:
server-id = 2
master-host = 192.168.56.101
master-connect-retry = 60
master-user = slave
master-password = 123
replicate-do-db = base1
replicate-do-db = base2
relay-log = /var/lib/mysql/slave-relay.log
relay-log-index = /var/lib/mysql/slave-relay-log.index
However, doing so also won't let me start mysql. When I run /etc/init.d/mysql start, it fails. These are the two errors that appear on the logs:
error: Can't connect to local MySQL server through socket '/var/run/mysql/mysqld.sock' (2)
Failed to start LSB: Start and stop the mysql server database daemon
Commenting the master-zzz lines allow mysql to start without a hitch.
The virtual machines can see each other and ping without loss. I've tried changing the my.cnf's master-user and password, as well as creating different replication slave users on the master server, to no avail. What am I doing wrong?
Well, turns out the tutorials I was following were a bit outdated. These are the final configurations of my.cnf files:
#master
bind-address = 0.0.0.0
server-id = 1
log-bin= /var/log/mysql/mysql-bin.log
#slave
server-id = 2
Instead of setting the slave's my.cnf, I used the mysql console:
CHANGE MASTER TO master_host='master_ip', master_user='slave', master_password='slavepass';
As per this manual's instructions: https://downloads.mysql.com/docs/mysql-replication-excerpt-5.0-en.pdf
Related
MySQL server + phpmyadmin
On the replication tab, it looks like someone already configured the master replication:
However, I do not see the following lines in my.cnf, which should have been added at the time the master was configured :
server-id=*****
log-bin=******
log-error=*****
How do I retrieve those values? Or how do I reset the master configuration so that I can perform the whole process myself (I also want to select/ignore new databases)?
I finally managed to solve my issue.
Note: The server-id is just a unique identifier that you can chose.
I had to enter those lines in the master's my.cnf file:
#master my.cnf
server-id = 1
log_bin = /var/lib/mysql/mysql-bin.log
binlog_do_db=database1
binlog_do_db=database2
binlog_do_db=database3
binlog_do_db=database4
binlog_do_db=database5
And those lines in the slave's my.cnf file:
#slave my.cnf
server-id = 2
replicate-do-db=database1
replicate-do-db=database2
replicate-do-db=database3
replicate-do-db=database4
replicate-do-db=database5
Then on the slave server's phpmyadmin go to replication tab and click Stop SQL Thread only and Stop IO Thread only
MySQL won't restart when I try "service mysqld restart"because I'm using this part in my.cnf
master-host = [private-IP-of-db01]
master-user = [replication-username]
master-password = [replication-password]
master-connect-retry = 60
when I comment out these parts! MySQL restarts fine. Why is that so? Also I have to include these lines in my.cnf because of master slave replication and I can't omit them out.
Usually master host information on the slave mysql server is stored in "master.info" file and maintained there. You may want to start mysql without adding the configuration to your "my.cnf" file, the only configuration you may want to add is a "server_id" , Once mysql is up and running, you should setup slave with 'change master command....'.
I have 3 master servers, different DBs, I am trying to replicate into a single server. I am having a hard time getting them setup and current. I have Duplicate Entry errors on all 3 Channels. Skipping them manually is painful to say the least. Is there a way to auto sync to the correct position? I was under the impression that this was easy as pie with GTID.
I used:
Dump:
mysqldump --databases profiles --single-transaction --triggers --routines --host=10.10.10.10 --port=3306 --user=user --password=pass > ~/dump.sql
Initialize:
CHANGE MASTER TO MASTER_HOST="10.10.10.10", MASTER_PORT=3306, MASTER_USER="user", MASTER_PASSWORD="pass", MASTER_AUTO_POSITION=1 FOR CHANNEL "channel1";
Master My.cnf:
gtid_mode = ON
enforce_gtid_consistency = true
log_bin = /var/log/mysql/bin_log.index
log_slave_updates = true
server-id = 2061
Slave My.cnf:
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
[mysqld_safe]
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
server-id = 10001
explicit_defaults_for_timestamp
gtid_mode=ON
enforce_gtid_consistency=true
log_bin=/var/log/mysql/bin_log.index
log_slave_updates=true
master_info_repository=TABLE
relay_log_info_repository=TABLE
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
#bind-address = 127.0.0.1
log-error = /var/log/mysql/error.log
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
Am I missing something? Any help is appreciated.
The problem was that GLOBAL.GTID_PURGED had only registered one of my master databases, which sets the proper position from which to continue the replication process.
The other databases were starting from the beginning of time essentially.
Thus the improper positioning and the Duplicate record errors I was receiving.
So this was my solution:
MySQL Multi-Source GTID Replication Guide by ME:
Re/Install MySQL Server:
After securing the current data I performed a clean install of MySQL Server 5.7.7-rc onto the slave server. Any MySQL Server can be completely removed using the following:
$ sudo apt-get --purge remove mysql-client mysql-server mysql-common
$ sudo apt-get autoremove
and then selecting YES at the prompt to remove the "Data" directory (This will permanently delete all of your databases, configurations, etc.). If you have any custom configurations, now is the time to backup your /etc/mysql/my.cnf file.
Reinstall MySQL Server 5.7 for Ubuntu 14-lts
$ sudo apt-get install mysql-server-5.7
If you don't have 5.7 on your system use this guide
Backup Live Master Databases:
I created a current MySQL Dump of all 3 Live Master databases. Each of my databases have a different name e.g. db01, db02, db03 and they are being saved directly onto the slave server.
In my case each database is on its own server, so I ran this a few times changing the ip and database, and filename.
$ mysqldump -u username -p -h 10.10.10.10 --skip-lock-tables --single-transaction --triggers --routines --databases db01 > ~/dumpDB01.sql
Once complete, you will need the GTID_PURGED data from each dump and save it for later:
$ grep PURGED ~/dumpDB01.sql
SET ##GLOBAL.GTID_PURGED='d23dceda-08a4-11e5-85e4-005056a2431f:1-10073';
You will need this entire string: d23dceda-08a4-11e5-85e4-005056a2431f:1-10073
MySQL Slave Server Configuration:
Now I decided to completely configure mysql before I ever imported any data and I will explain why shortly.
Edit my.cnf:
sudo vi /etc/mysql/my.cnf
gtid_mode =ON
enforce_gtid_consistency =true
log_bin =/var/log/mysql/bin_log.index
log_slave_updates =true
master_info_repository =TABLE
relay_log_info_repository =TABLE
server-id =1001
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
#bind-address = 127.0.0.1
You will need to save the configuration file and create the bin_log.index file, otherwise the server will not start.
$ sudo touch /var/log/mysql/bin_log.index
$ sudo chown mysql:mysql /var/log/mysql/bin_log.index
$ sudo service mysql restart
Import / Configure Data:
While importing the dumps, the first one will register its GTID_PURGED automatically like this:
SET ##GLOBAL.GTID_PURGED='d23dceda-08a4-11e5-85e4-005056a2431f:1-10073';
Once this happens your GTID_EXECUTED will be set with the same data, and each subsequent import will produce errors like this:
ERROR 1840 (HY000) at line 24: ##GLOBAL.GTID_PURGED can only be set when ##GLOBAL.GTID_EXECUTED is empty.
These errors can be ignored on import with $ mysql -u username -p -f < ~/dumpDB02.sql as we are going to modify the GTID_PURGED manually after the import process. If you have already forced the imports and have seen this error you can clear both GTID variables by executing mysql > RESET MASTER;
From the mysql console run the following:
mysql> RESET MASTER;
You will need all 3 GTIDs from the dumps and comma separate them in the assignment below.
mysql> SET ##GLOBAL.GTID_PURGED='d23dceda-08a4-11e5-85e4-005056a2431f:1-10073,d23dceda-08a4-11e5-85e4-005056a2431f:1-10073,d23dceda-08a4-11e5-85e4-005056a2431f:1-10073';
You can now initialize and start replication:
For each database (in my case I changed the ip and channel is a string of your choice. You will use this channel to access the slave data):
mysql> CHANGE MASTER TO MASTER_HOST="10.10.10.10", MASTER_PORT=3306, MASTER_USER="username", MASTER_PASSWORD="password", MASTER_AUTO_POSITION=1 FOR CHANNEL "db01";
Then start each slave:
mysql> START SLAVE FOR CHANNEL "db01";
mysql> SHOW SLAVE STATUS FOR CHANNEL "db01"\G
and success!
I have all of the data, no errors, and its now up to date with the Master Servers
In-Short: My binary logs aren't starting even though log-bin is set and specified. I'm not sure how to fix it.
I have a MariaDB instance running as a service on windows that I am attempting to replicate to a MariaDB instance on a Ubuntu machine. I am using MySQL workbench 6.0 as much as I can to manage everything, and following the instructions from Oracle here for setting up master-slave replication: http://dev.mysql.com/doc/refman/5.0/en/replication-howto.html
I have made it to the fourth chapter, where I allegedly have the master and slave both configured, and I am about to read-lock the master tables for an initial data dump to the slave before I start up replication. So I flushed the tables with read lock and checked the master status:
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
That last line didn't return any binary log information. Checking further, I ran:
SHOW BINARY LOGS;
and an error message confirmed that:
Error Code: 1381. You are not using binary logging
Master Config is like this:
[mysqld]
datadir = "C:/mysql/data"
port=3306
sql_mode="STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"
default_storage_engine=innodb
innodb_buffer_pool_size=1535M
innodb_log_file_size=50M
feedback=ON
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
log-bin-index = "C:/mysql/logs/log-bin.index"
log-bin=mysql-bin
server-id=1
innodb_flush_log_at_trx_commit=1
[client]
port=3306
How do I make sure the binary logs are rolling so I can continue with this?
I currently have one master server and want to add another master server for fail over.
On the primary server I've added the following to "my.ini"
server-id = 1
replicate-same-server-id = 0
auto-increment-increment = 2
auto-increment-offset = 1
log_bin=mysql-bin
log_error=mysql-bin.err
binlog_do_db=1
binlog_do_db=2
binlog_do_db=3
binlog_do_db=4
Once adding:
master-host = [IP]
master-user = [usernameslaveuser]
master-password = [password]
master-connect-retry = 30
The mysql server no longer starts up...
So I decided to first get the secondary server to work properly.
Problem 2:
On the new server I've copied over my user files from the "data"/mysql dir of the primary.
I've also imported all databases with MySQL work bench.
Then I added this to "my.ini":
server-id=2
replicate-same-server-id = 0
auto-increment-increment = 2
auto-increment-offset = 2
master-host = [IP]
master-user = [usernameslaveuser]
master-password = [password]
master-connect-retry = 30
log_bin=mysql-bin
log_error=mysql-bin.err
binlog_do_db=1
binlog_do_db=2
binlog_do_db=3
binlog_do_db=4
The server starts up fine, so I decided to add a table inside a replicating database on the master but the changes where not copied over to the secondary server...
I googled a bit and found that I have to run some commands in the mysql command line to make replication work.
But when I open this on the secondary server it doesn't start...
When opening it in the command prompt it says mysql.exe: unknown variable 'server-id=2"
Both servers are running Windows Server 2012 R2 and have MySQL 5.6.15 64bit installed.
Can someone guide me true the last part of setting this up?
Specifying as below in my.cnf(linux) or my.ini(windows) file is no longer supported in latest versions of MySQL
master-host = [IP]
master-user = [usernameslaveuser]
master-password = [password]
master-connect-retry = 30
You should execute this query instead:
CHANGE MASTER TO MASTER_HOST='host name/ip',MASTER_USER='user',MASTER_PASSWORD='pwd', MASTER_PORT=3306, MASTER_CONNECT_RETRY=30;
I've resolved problem 2: I wasn't putting it in the mysqld part but in the mysql part of the my.ini
Resolved problem 1: had to run it in the MySQL command line.