Is there any specific reason for not able to use slave parallel workers while working with lower version of master which not supports parallel workers and higher version of slave which supports parallel workers.
Here i am trying MASTER ( 5.5.28 ) and slave (5.6.19)
See this presentation MySQL Replication High Performance: Multi-Threaded Slaves and
Group Commit
It is stated with respect to the multi threaded replica (MTS):
Row Based Replication is supported even if replicating from a Master without MTS knowledge (e.g., from a 5.5 MySQL master).
Statement Based Replication requires a 5.6 master.
Re questions from #vidyadhar:
I don't know if replica performance will be worse if the master is 5.5. I haven't tried that. I don't mean to sound flippant, but if performance is so important to you, why wouldn't you upgrade to 5.6?
Regarding statement based replication and multi-threaded replica, I have not tested that combination. But I have not read any requirement to use row based binlog format for MTS. I assume it would work fine, because the MTS delegates events to replica worker threads based on the database, and every event in the binlog identifies the default database for the event, whether the event is in row based or statement based format.
Related
We are currently using binary replication from our master to slave.
Is it possible to enable the GTID on the slave only? (this is required from some other application reading from the replicas, but we don't want to make changes to master)
Are there any reasons why this should not be possible?
See https://dev.mysql.com/doc/refman/8.0/en/replication-mode-change-online-enable-gtids.html:
From MySQL 8.0.23, you can set up replication channels to assign a GTID to replicated transactions that do not already have one. This feature enables replication from a source server that does not use GTID-based replication, to a replica that does.
Read the rest of the documentation I linked to for more details.
I understand this paragraph to mean you cannot do what you describe on a version older than 8.0.23. If you want to do this, you must upgrade at least the replica to 8.0.23.
However, I'd recommend that you enable GTID on your source instance, not just the replica. You can do this on older MySQL versions, and there are other advantages to using GTID throughout your replica-set. I don't know why you don't want to do this, but I'm not able to think of a good reason.
In case of MySQL 5.7, it is not possible to enable the GTID in replica only. Follow this guide to enable the GTID: https://dev.mysql.com/doc/refman/5.7/en/replication-mode-change-online-enable-gtids.html
I have two mariadb servers one is configured as master and the other as a replica of this master. I have created a database named params on master and it has a table with a couple of items in it.
How can I see this table and access or modify it using the mysql shell on the replica?
Is this even possible or I have miss understood the replication altogether?
Check that replication works
If you aren't seeing the database on the slave replica, it would be good to check that the output of SHOW SLAVE STATUS doesn't return any errors. A good resource for getting started with replication is the MariaDB KB article on the subject.
When you have confirmed that replication works, you can connect to the slave replica and you should see the database there.
How replication works in MariaDB
Replication in MariaDB will propagate all changes that happen on the master server to any slave servers that are replicating from it. This allows you to read the same data from multiple places without burdening the master server. It does not allow you to seamlessly share data across multiple servers (a Galera cluster offers some of this).
The downside of master-slave replication is that when you want to make a change, you have to make it on the master in order to keep the data consistent across all servers. The benefit of it is the higher availability of your data and increased throughput of read queries. The Replication Overview article has a more detailed description of what replication is and lists some use cases for it.
I have setup a small cluster using two MariaDB 10.2 databases, one is (active) master and the other standby (passive master). I have enabled GTID and semi-synchronous replication. Say that MDB1 is master and MDB2 is standby, therefore MDB2 replicates MDB1 binlog and MDB1 replicates MDB2 binlog. Of course I write only on MDB1 to avoid conflicts.
My concern is about JDBC parameter: I cannot really understand the difference between failover, replication and sequence.
jdbc:mariadb:replication://localhost:3306,localhost:3307/mydb
Using replication as above it seems to write always on MDB1 (:3306) and to read both from MDB1 and MDB2, right?
In the case I want to write and read always to from MDB1, unless it becomes unavailable, which is the correct setup?
And how can I avoid inconsistencies when MDB1 became available again? Is this guaranteed by the usage of GTID?
I have followed those guides:
Availability with MariaDB TX: The Definitive Guide p11
Failoverand High availability with MariaDB Connector/J
What you should use is sequential
According to the documentation,
'''
if the failover and load-balancing mode is set to replication, then the connector assumes that the first host is master, and the others are slaves by default, if their types are not explicitly mentioned.
'''
I'm kind of lost there, I want to setup a common MASTER/SLAVE replication on a MariaDB database. I choose MASTER/SLAVE over MASTER/MASTER to avoid complexifying things. The SLAVE will be used only if the MASTER server is down.
I've setup MariaDB 10.0.x, but when I start reading on how to achieve this replication, they introduce Galera, which, if I understand correctly, replaces MariaDB.
What do you use to tell the SLAVE server to take the relay if the MASTER server is down ? Is it handled automatically via the Galera Cluster ?
If possible, I don't want my application to be aware of the slave server : I just want to configure it with the IP of MariaDB MASTER, and if it can't be reached, to use the SLAVE instead. (But I do not want to specify this fallback in the application level)
Thanks
What you are looking for can be achieved. I just completed a setup of MariaDB 10 using asynchronous replication (not Galera). To ensure maximum uptime I setup master / master replication and used mysql-mmm to monitor the setup. This tool will manage a virtual IP and point it at one of the two masters for writing purposes. This ensures consistent writes against a single master as to avoid corruption of the data. If one master fails the virtual IP will be mapped to the other master. This provides the high availability aspect. The instructions stated below were very clear and easy to follow.
http://mysql-mmm.org/mmm2:guide
Good luck!
Using simple replication settings with one MASTER and one SLAVE, how can one ensure that the SLAVE and MASTER are fully synchronized?
Now yes, they both started from the exact same image and replication is working and reporting that everything is okay BUT:
* It has happened that there were errors stopping the replication and then the replication had to be stopped and later resumed.
* Perhaps a change accidentally occurred on the SLAVE and then it's not the same as the MASTER anymore.
* Other whichever scenarios that might break sync.
While it's possible to do a big mysqldump of both database and compare the files I would be interested in a method that can be implemented more easily and also can be checked automatically to ensure all is in sync.
Thanks
Have you tried Percona Toolkit (formerly known as Maatkit)? You can use one of their tools which is pt-table-checksum for your case. You can check other tools too at their website.
pt-table-checksum performs an online replication consistency check by
executing checksum queries on the master, which produces different
results on replicas that are inconsistent with the master. The
optional DSN specifies the master host. The tool’s exit status is
nonzero if any differences are found, or if any warnings or errors
occur.
The following command will connect to the replication master on
localhost, checksum every table, and report the results on every
detected replica:
If you have MySQL Server versions 5.6.14 or higher, you can use the MySQL Replication Synchronization Checker. It's included in the MySql server package. Is designed to work exclusively for servers that support global transaction identifiers (GTIDs) and have gtid_mode=ON.
This utility permits you to check replication servers for synchronization. It checks data consistency between a master and slaves or between two slaves. The utility reports missing objects as well as missing data.
The utility can operate on an active replication topology, applying a synchronization process to check the data. Those servers where replication is not active can still be checked but the synchronization process will be skipped. In that case, it is up to the user to manually synchronize the servers.
See MySQL Documentation for more information
You are right to be suspicious of a seemingly healthy master/slave replication setup! We were running fine when suddenly we got alerts from check_mk concerning a database that existed on our master that did not exist on our slave... but the master and slave status outputs were good! How unnerving is that? The way to prove integrity of the process is to use checksums to verify the data.
I have seen a lot of chatter on the Internet recommending pt-table-checksum . However, its limitations proved to be too onerous for us to be comfortable with. Most importantly, it requires and even sets statement-based replication (see the pt-table-checksum link). As it says in the mysql 5.6 online documentation, (for row-based replication...) "all changes can be replicated. This is the safest form of replication." There are other disadvantages to statement-based replication that make our developers nervous because some functions cannot be replicated properly; see the doc for a list.
We have already experienced issues with a master and slave using statement-based replication so we're specifically trying to avoid it.
We are going to try mysqlrplsync which specifically mentions that it "works independently of the binary log format (row, statement, or mixed)". It also mentions, however, that gtid-mode must be on and it requires MySQL 5.6.14 and higher... which means, I believe, that the MySQL delivered with RHEL7/CentOS 7 at least is out. You'll need to get the MySQL Community Edition, which is left as an exercise for the reader but you can go here for the packages or here for the repos, including RHEL derivatives and Debian.