I'm doing a migration work from MySql to MariaDB where replication is involved, everything is working fine and compatibility of master MySql (5.5.59) to slave MariaDB (10.1.26) is good.
The problem occur when I enable the replication from MariaDB master to MariaDB slave (same versions: 10.1.26). In some situations, identified on massive updates, the slave start to lag.
If I restore the master to MySql (5.5.59) and I replicate to the same slave in MariaDB, the lag never occur on the same set of updates.
I checked the relay logs in the MariaDB slave that is lagging, comparing the ones received when MySql is the master and the ones received when MariaDB is the master, the only differences are that when the master is MariaDB I can see statements related to gtid.
I would like to disable the presence of the gtid statements on the relay log when the master is MariaDB and make a replication similar to the "old style" MySql replication without gtid, but I've not found if is possible to do that.
The replication lag was due to the engine set in the table mysql.gtid_slave_pos in the slave server, by default this table is InnoDB and the tables that were receiving the replication updates are not InnoDB.
As explained in the link below, every transaction executed by the slave cause also an update on mysql.gtid_slave_pos, if the engines of the tables are different, that can cause a bad performance (in my case the server was lagging 4000+ seconds, changing the engine in the mysql.gtid_slave_pos the replication is now immediate).
https://mariadb.com/kb/en/library/mysqlgtid_slave_pos-table/
From MariaDB 10.3.1, a new parameter has been introduced to help with this problem: gtid_pos_auto_engines This parameter will create a different table mysql.gtid_slave_pos for each engine involved in the replication. Unfortunately seems not possible to accomplish that with previus version of MariaDB, the table mysql.gtid_slave_pos must be unique and the choice of its engine is up to the DBA and the tables/queries involved in the replication
Related
I have a problem with MySQL replication - there is one table on master server which doesn't appear on slave server. Both master and slave has the same master_log_file and master_log_position, both slave_io and slave_sql threads are running, I even tried to add an empty table to the master database but it does appear on the slave database. It's not the first time I got such error but before that my symptopms were new data did not appear in slave database. Are there any other solutions for this problem than stopping replication on the slave, dropping the database, dumping it on master server, rsyncing to slave server and restarting replication from new file/position?
I noticed using
SHOW SLAVE STATUS;
that Relay_Log_Pos is smaller than Read_Master_Log_Pos and Relay_Log_File differ from Master_Log_File but Slave_SQL_Running_State says
Slave has read all relay log; waiting for more updates
Seconds_Behind_Master says 0.
MySQL officially only supports replication to the next higher version (although it will work for 5.7.13+), see Replication Compatibility Between MySQL Versions:
MySQL supports replication from one release series to the next higher release series. For example, you can replicate from a master running MySQL 5.5 to a slave running MySQL 5.6, from a master running MySQL 5.6 to a slave running MySQL 5.7, and so on.
However, you may encounter difficulties when replicating from an older master to a newer slave if the master uses statements or relies on behavior no longer supported in the version of MySQL used on the slave.
By default, replication will stop if an error occurs, and you have to restart it (after fixing the error). If you use the --slave-skip-errors=all-option however, it will skip these errors:
Normally, replication stops when an error occurs on the slave, which gives you the opportunity to resolve the inconsistency in the data manually. This option causes the slave SQL thread to continue replication when a statement returns any of the errors listed in the option value.
Do not use this option unless you fully understand why you are getting errors. If there are no bugs in your replication setup and client programs, and no bugs in MySQL itself, an error that stops replication should never occur. Indiscriminate use of this option results in slaves becoming hopelessly out of synchrony with the master, with you having no idea why this has occurred.
MySQL 5.5. and 5.7. will actually behave differently for a lot of statements, so enabling this option in this scenario will require even more care.
Without seeing your actual table create-statement, it is unclear what exactly caused that problem and how to fix it (or if it is possible), but you should especially check your configuration settings. MySQL 5.7. enables strict mode by default, so a usual suspect for incompatibilites is e.g. a zero default value for date/timestamp-columns like default '0000-00-00' (either explicit or implicit), which is not allowed anymore, see no_zero_date.
Even if you seem to not be too keen about 100% replication (which can snowball very fast, but that is up to you to evaluate for your scenario), resetting your slave (after fixing e.g. the configuration settings) at least once is probably the easiest solution, as there might have been other things you may have missed, and, if executed without errors, will also doublecheck if your tables and data up to that point are compatible with your 5.7-slave now.
I have a MySQL Replication setup up and running:
Database A (Server 1 as master) --> Database A (Server Z, acting as the slave)
I now want to use the same Slave Server (Z) to be a slave of two other databases; totally different databases (e.g. B and C), not other copies if Database A.
I've followed this simple guide:
https://www.digitalocean.com/community/tutorials/how-to-set-up-master-slave-replication-in-mysql
But when it comes to adding the second database to the slave server in /etc/my.cnf, I don't see how it's possible to have more than one profile.
Basically I am thinking I need both of these blocks in my.cnf on the slave server but it won't be that simple, right?
log_error="/var/log/mysql/error.log"
server-id=2
log_bin="/var/log/mysql/mysql-bin.log"
binlog_do_db=database_a
log_error="/var/log/mysql/error.log"
server-id=3
log_bin="/var/log/mysql/mysql-bin.log"
binlog_do_db=database_b
Is it possible, or do I literally need a new slave server for each unique database I want to replicate?
Is it possible to, on the slave server, have specific conf files for each database, e.g. /etc/databasea.cnf and /etc/databaseb.cnf so I can specify different settings for each database?
Thanks in advance
Multi-source replication is only available in MySQL starting with 5.7.6 or MariaDB starting with 10.0.1.
Multi-Source Replication enables a replication slave to receive transactions from multiple sources simultaneously. Multi-source replication can be used to back up multiple servers to a single server, to merge table shards, and consolidate data from multiple servers to a single server. Multi-source replication does not implement any conflict detection or resolution when applying the transactions, and those tasks are left to the application if required. In a multi-source replication topology, a slave creates a replication channel for each master that it should receive transactions from.
Source:
MySQL : http://dev.mysql.com/doc/refman/5.7/en/replication-multi-source.html
MariaDB: https://mariadb.com/kb/en/mariadb/multi-source-replication/
Using master-slave replication, can I write to a table on the slave that DOES NOT exist on the master and never will, without interfering with replication with out-of-sync errors?
The master and slave both have bin logs enabled.
Will I break the replication doing that?
If your replication is set in master ---> slave mode, there is no problem in writing to a slave table, even if the table is present in master. It wont affect the replication process. In your case, the only possible cause for a replication failure would be when you create a table in your master, which is already in the slave.
So the answer for your question is your replication won't break if you do this.
Here is a good refernce
I have setup MySQL replication with Percona 5.5.25a server as a slave for MySQL 5.0.95 master. Slave is very slow in catching up with master. It is lagging behind master for around 4 days now. Both the master and slave runs on VM nodes. Physical configuration of both the nodes are same. MySQL configuration is also same on both.
When I change the slave to 5.0.95, slave immediately catches up and never lags behind master.
I am using Innodb as the engine. Initially, when the replication started, Innodb status on the slave showed that there were locks on a table during replication. Each update on this table was causing the locks to be held for around 15 to 20 mins. I have ignored this table in replication. After this, there are no locks observed in the slave. But the QPS on slave is only 4. With this rate, the slave is never to going to catch up with the master.
Any suggestions on how to resolve this will be much appreciated.
SHOW ENGINE INNODB STATUS
to inspect any deadlock reasons!
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.