I am about to do a MySQL replication for my typo3 Database. There are two servers. You guessed it one is the Master and one is the Slave.
Master my.cnf:
[mysql]
server-id = 1
log-bin
expire_logs_days = 21
max_binlog_size = 500M
binlog-ignore-db=mysql
Slave my.cnf:
[mysql]
server-id = 2
binlog-ignore-db = mysql
replicate-ignore-db = mysql
auto-increment-offset = 1
expire_logs_days = 21
max_binlog_size = 500M
User on Master: repl#slaveip REPLICATION SLAVE, REPLICATION CLIENT
User on Slave: repl#masterip REPLICATION SLAVE, REPLICATION CLIENT
So far everything works, even if I change something on Master but if I delete the same thing on Master, Slave stops with this error message:
Last_SQL_Error: Error 'Duplicate entry '65021' for key 'PRIMARY'' on query. Default database: 'typo3'. Query: 'INSERT INTO sys_log (userid,type,action,error,details_nr,details,IP,tstamp,workspace) VALUES ('0','5','0','2','0','Core: Exception handler (WEB): Uncaught TYPO3 Exception: Reason: Segment "404" was not a keyword for a postVarSet as expected on page with id=0.<br />\n<br />\nAdditionally, http://www.21cdocs.de/404/ was not found while trying to retrieve the error document. | RuntimeException thrown in file /mnt/platte02/www/typo3/typo3_src-4.5.19/typo3/sysext/cms/tslib/class.tslib_fe.php in line 1542','masterip','1351240603','0')'
This is what show slave status\G shows me.
Any solutions how I force the Slave to override everything on it with Masters data?
- Timo
With slave-skip-errors = 1062 it skips the error but this isn't a good solution in my opinion
Update: obviously Typo3 is doing some mistakes on the sys_log table.
Related
The question is about MySQL-Master-Master replication. I have read a lot on the Internet, but there is a problem.
Source data:
A. MySQL 5.7.
Part of my. cnf about replication:
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
log_bin_index = /var/log/mysql/mysql-bin.log.index
relay-log = /var/log/mysql/mysql-relay-bin
relay-log-index = /var/log/mysql/mysql-relay-bin.index
binlog_do_db = example
expire-logs-days = 7
auto_increment_increment = 2
auto_increment_offset = 1
log-slave-updates = 1
B. MySQL 5.7.
Part of my.cnf about replication:
server-id = 2
log_bin = /var/log/mysql/mysql-bin. log
log_bin_index = /var/log/mysql/mysql-bin.log.index
relay-log = /var/log/mysql/mysql-relay-bin
relay-log-index = /var/log/mysql/mysql-relay-bin.index
binlog_do_db = example
expire-logs-days = 7
auto_increment_increment = 2
auto_increment_offset = 2
log-slave-updates = 1
Server A is the active (primary) database server. Server B connects when server A is disabled / unavailable. In the beginning, the Master-Master replication was assembled (replication worked in both directions) and successfully worked for 2 days until I decided to test it. I started blocking access to server A to switch to server B and back. After several switches replication error 1062 appeared (Could not execute Write_rows event on table...).
And now question. What is incorrectly configured in my replication configuration? I understand that a lot depends on the product and the requests to it, but is there a universal Master-Master config?
Please consider below steps to test connection or failover:
let's assume, server A is active. So
enable read only first on server A.
then wait for couple of seconds and check show slave status twice
if positions are not changing. then move traffic on server B.
Follow same steps to reverse traffic on server A.
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
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;
I'm trying to setup master-slave replication between 2 mysql servers on CentOS. Once setup if I create a database called 'fakeDB' on the master it creates it on the slave. Awesome! But if I then try to create a table on the master I get this error on the slave:
Last_Errno: 1049
Last_Error: Error 'Unknown database 'fakeDB'' on query. Default database: 'fakeDB'. Query: 'create table tmp (name varchar(100))'
But the database exists on the slave! So I then started over and created the database and tmp table on both servers. I reset everything and then tried to insert a row on the master. I then got this error on the slave:
Last_SQL_Errno: 1146
Last_SQL_Error: Error 'Table 'fakeDB.tmp' doesn't exist' on query. Default database: 'fakeDB'. Query: 'insert into tmp values ('asdf')'
But again that database exists and so does the table on both servers. I can access them manually. Here is the variables I set in the my.cnf file on both servers.
server-id = 1 #set as 2 for master
log_bin = /var/lib/mysql/mysql-bin.log
relay-log = /var/lib/mysql/mysql-relay-bin.log
binlog_do_db = fakeDB
What am I doing wrong?
Ok. I figured it out. Turns out it was something stupid. I had this option set in my configuration file on the slave:
lower_case_table_names=1
So when I created the database on the master as fakeDB it created it on the slave as fakedb. So on the slave I can issue use fakeDB; and it works because the command is case insensitive but then the queries issued from the master weren't so insert into fakeDB.tmp failed because the database name is fakedb.
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?