Mysql slave gets ruined after a restart - mysql

Please help!
I set up a master-slave replication based on the GTID mechanism.
The replication works OK, until a mysqld restart happens on slave. Then the mess begins...
After such a restart, I can not restore the replication.
When issuing a "START SLAVE" command I get the following an error message:
ERROR 1794 (HY000) at line 1: Slave is not configured or failed to
initialize properly. You must at least set --server-id to enable
either a master or a slave. Additional error messages can be found in
the MySQL error log.
Needless to say I did set server-id in my.cnf (see below).
In /var/log/mysqld.log file, I found the following error message:
[ERROR] Error creating master info: Multiple replication metadata
repository instances found with data in them. Unable to decide which
is the correct one to choose.
[ERROR] Failed to create or recover replication info repository.
I can not understand what have I done wrong.
The communication between master and slave is ssl-tunneled through stunnel, but I don't think this is a relevant fact, since until a restart everything works right.
The only way I found to re-establish the replication (after mysql restart) is to manually delete the mysql data files, and then load again the dump file imported from the master. (I use mysqldump). This is of course unreasonable.
Following are the my.cnf files:
On slave:
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Recommended in standard MySQL setup
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
server-id=2
log-bin=mysql-bin
binlog_format=ROW
relay_log=relay-log
skip-slave-start
enforce-gtid-consistency
gtid-mode=ON
log-slave-updates
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
On mater:
[mysqld]
server-id=1
log-bin=mysql-bin
binlog_format=ROW
gtid-mode=on
enforce-gtid-consistency
log-slave-updates
innodb_buffer_pool_size = 1G
query_cache_size = 32M
Slave machine: Centos 6.6, mysql 5.6.24.
Master machine: RHEL 6.6, mysql 5.6.10.
Any help wold be greatly appreciated!
Thanks
Nadav Blum

on master -
mysql> reset master;
[this command will clear binary logs of master and start with new. so save it if you want.]
when you start the slave mysqld, run the following command
mysql> stop salve;
mysql> reset slave;
mysql> change master to master_host='192.168.10.116', master_user='root', master_password='root', master_auto_position=1;
mysql> start slave;
mysql> show slave status \G
Now if all goes well then, you can restart the slave (if it is committed all the transaction then no problem else it will start to execute transection in your master binary log. You can check your relay log file)

Well, mystery solved.
Remember how I wrote that the issue has nothing to do with my usage of stunnel, as the mean for tunneling communication between master and slave ?
Well, I was wrong.
The thing is, I used localhost port 3307 as the end point for the slave communication to the master. (stunnel listened to this port and forwarded data to the master-server ip). So the "change master" was done via:
change master to master_host="localhost", master_port=3307, master_user="XXX", master_password="XXX", MASTER_AUTO_POSITION = 1;'
That "localhost" thing caused the mess. I changed it to "127.0.0.1", and now restarts cause no harm!
Thanks Hitech and Jaydee for your help!

Ran into the same problem yesterday.
Oracle support doc helped.
For people who don't have Oracle support.
CAUSE
The cause is that both TABLE and FILE replication repository metadata exist at the same time, but only one form should.
SOLUTION
Before setting up replication, remove the files specified by the my.cnf variables relay_log_info_file and master_info_file .
By default their names map to relay-log.info and master.info and they are located in the datadir. (I had to remove the master.info file)
And remove any residual configuration by executing:
STOP SLAVE;
SET SQL_LOG_BIN=0;
DELETE FROM mysql.slave_master_info ;
DELETE FROM mysql.slave_relay_log_info ;
SET SQL_LOG_BIN=1;

Related

MySQL - PhpMyAdmin Replication Reset Master Configuration to retrieve server-id

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 daemon failed to start

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....'.

Same ID error when I try to replicate databases

I'm not able to replicate a database from a live server to local server(which is accessible from outside).
I got this error on master server
Fatal error: The slave I/O thread stops because m
aster and slave have equal MySQL server ids; these ids must be
different for rep
lication to work (or the --replicate-same-server-id option must be
used on slave but this
does not always make sense; please check the manual before using it).
On the master server when I type SHOW SLAVE STATUS \G
On Phpmyadmin I got this error:
Slave IO Thread not running!
my master my.cnf file
[mysqld]
local-infile=0
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
server-id=1392211409
log-bin=mysql-bin
log-error=mysql-bin.err
binlog_do_db=vapes4you
binlog_format=ROW
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
my slave file is
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
server-id=1392211002
master-host=********
master-user=vapesbackup
master-password=********
master-port=3306
replicate-do-db=dbname
master-connect-retry=60
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
could anyone help me? thanks for reading
If command show variables like 'server_id'; gives you different IDs, then it is possible that you entered it's own IP address, when setting up replication.
CHANGE MASTER TO MASTER_HOST = **'**192.168.1.155**'**, MASTER_USER = 'replicator', MASTER_PASSWORD = 'passwd', MASTER_LOG_FILE = 'mysql-bin.000002', MASTER_LOG_POS = 107;
Are you sure that the slave server uses this my.cnf file?
Please run this command on both servers and compare IDs:
show variables like 'server_id';
Try Commenting out the server-id of SLAVE server while keeping the master intact. Then restart both.
In my case I was using a custom my.cnf file that was not being used to execut MySQL Server.
Press Windows Key + R;
Type %ProgramData%;
Search for MySQL/MySQL Server 8.0 or equivalent;
Update your my.ini file.
First of all, you have to stop your slave by this command,
STOP SLAVE;
Then go to your master replica.
SHOW MASTER STATUS \G;
Then you will get the log file and the PID. Which you will need to add in slave. Go to your slave and then add this command.
CHANGE MASTER TO
MASTER_HOST=IP_ADDRESS,
MASTER_USER=USER_ID,
MASTER_PASSWORD=YOUR_PASSWORD,
MASTER_LOG_FILE=YOUR_LOG_FILE_NAME,
MASTER_LOG_POS=YOUR_PID;
Then start your slave.
START SLAVE;
I hope this will help to start your slave safely.

MySQL binary logs will not start

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?

Error: "could not initailize master info structure" while doing Master Slave Replication in MySQL

I am trying to do Master Slave Replication for MySQL. When i am typing the following command:
CHANGE MASTER TO MASTER_HOST='10.1.100.1', MASTER_USER='slave_user', MASTER_PASSWORD='slave_password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=451228;
mysql> START SLAVE;
it throws the following error:
ERROR 1201 (HY000): Could not
initialize master info structure; more
error messages can be found in the
MySQL error log
Any help would be greatly appreciated.
TRY TO RESET IT, IT DOES MAGIC! ON SLAVE THE SLAVE MYSQL COMMAND TYPE:
RESET SLAVE;
THEN TRY AGAIN:
CHANGE MASTER TO MASTER_HOST='10.1.100.1', MASTER_USER='slave_user', MASTER_PASSWORD='slave_password', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=451228;
mysql> START SLAVE;
Please check several things:
1) Make sure the Master's /etc/my.cnf has server_id actually set
Here is why: Replication relies on the server_id. Whenever a query is executed and is recorded in the master's binary log, the server_id of the master is recorded with it. By default, if a server_id is not defined in /etc/my.cnf, the server_id is defaulted to 1. However, the rules MySQL Replication demand that a server_id be explicitly defined in the master's /etc/my.cnf. In addition, for any given slave, mysqld checks the server_id of the SQL statement as it reads it from the relay log and makes sure it is different from the slave's server_id. That is how MySQL Replication knows it is safe to execute that SQL statement. This rule is necessary in the event Circular (Master-Master,MultiMaster) Replication is implemented.
use select ##server_id; in sql command line to check config really on server.
2) Make sure the Slave's /etc/my.cnf has server_id actually set
Here is why: Same reason as in #1
3) Make sure the server_id in the Master's /etc/my.cnf is different from the server_id in the Slave's /etc/my.cnf
Here is why: Same reason as in #1
As a side note : If you setup multiple slaves, please make sure each slave has a different server_id from its master and its sibling slaves.
Here is why : Example
A master with 2 slaves
MASTER has server_id 1
SLAVE1 has server_id 2
SLAVE2 has server_id 2
Replication will become agressively sluggish on SLAVE2 because a sibling slave has the same server_id. In fact, it will steadily fall behind, catch a break, process a few SQL statements. This is the master's fault for having one or more slaves with identical server_ids. This is a gotcha that is not really documented anywhere.
I've seen this dozens of times in my life time.
I had something very close to that and got same error messages.
Replication run fine, mariadb restart -> "cannot open relay log"
Solution from Neo helped in the first place.
But the root cause it seems were to small open file limits.
Try a lsof | wc and increase DefaultLimitNOFILE to 65535 in /etc/systemd/system.conf and /etc/systemd/user.conf
If nothing else helps and you are convinced everything is set correctly you will have to remove this file:
/var/lib/mysql/<relay_logname>-<connection>.info
after that perform the 'CHANGE MASTER' command as stated above