There are multiple ways to take a MySQL replication, or rebuilding it. How can we build master-slave replications via LVM snapshot?
And also which is the most effective way among below 4 choices & why ??
Setting up MySQL Replication using mysqldump.
Setting up MySQL Replication using Percona XtraBackup.
Setting up MySQL Replication using Rsync.
setting up MySQL Master-Slave Replication with LVM snapshots.
Since setting up LVM requires major surgery at the filesystem level, that approach could be a challenge. However, once it is done, the rest is relatively painless.
XtraBackup is an improvement on mysqldump.
rsync is good for copying files that are not being modified. When MySQL is running, it is modifying files, and caching unwritten stuff in ram. Sounds sketchy.
Related
I have two kubernetes cluster and I want to make master-master replication for Mysql database. As I read vitess documentation, that is convenient, but I don't know how to do that?
the data is more than 500G in mysql and maybe need sharding. how can I use vitess as Mysql cluster to have zero down time on database layer?
Vitess does not support master-master replication: https://vitess.io/docs/overview/scalability-philosophy/#no-active-active-replication
If zero downtime is your primary concern, then I recommend looking to Percona Xtradb Cluster or Mysql Group Replication, but these require very reliable network between cluster nodes and can easily cause more issues then solve if used incorrectly.
I want to do synchronous and asynchronous replication, synchronize for some databases, and asynchrony for others.
Asynchronous I am doing it through MariaDB, through the traditional system that has replication.
But I want to implement synchronous replication also with Mysql / MariaDB.
The problem is that I do not know if Mysql Cluster also does that work, or if it is not necessary to have Mysql installed only or MariaDb and only use Mysql Cluster for both.
Thank you.
Disclosure: I am working for the MySQL Cluster team - "MySQL Cluster" as in NDB Cluster.
MySQL NDB Cluster always uses synchronous replication between its nodes. You can still use asynchronous replication to other MySQL instances or MySQL Clusters.
AFAIK only MySQL offers NDB and as open source.
Due to the usual network limitations synchronous replication is better suited for high availability in the local data center. It gives you an always consistent view of your data, two or more active instances and makes programing against it much easier.
Asynchronous is more for replication between data centers or availability zones where you can live with temporary inconsistencies in the data and have your programming model set up accordingly.
"MySQL Cluster" has more than one meaning, so I will avoid it.
"Galera" is the underlying cluster technology in MariaDB, PXC, and (if you do the installation yourself), MySQL.
Galera provides essentially-synchronous among (typically) 3 nodes. Meanwhile, each node can have any number of asynchronous Slaves hanging off it.
Also, one Galera cluster can asynchronously replicate to another such cluster. This is sometimes done with a cluster in each of two datacenters.
Mixing sync and async at the database level is quite unusual, and seems strange. The general principle of Replication is that all servers will have exactly the same (barring delays) data. Please elaborate on what you want to do. Also, think out of the box when it comes to topologies.
I am handling few databases that is growing very fast. Now it is around 12GB and in next few months it will cross 15GB. At this situation I only have the traditional backup process mysqldump running in cronjob. I found significant delay in backup and restore time (hours, even days) for the whole database. Knowing that physical backups are much faster than logical, I found these two, but cannot implement those because of some limitations and company policy.
MySQL Enterprise Backup : which is commercial
Percona XtraBackup : Percona came with this tool specially for Linux environments. And not all companies will agree to use 3rd party tools even though it is open source.
Please suggest any other better backup and restore mechanism for big database specially when the databases are mix of Innodb and MyISAM. Looking for some good suggestions on snapshots
I have personally used Percona XtraBackup toolset. It does some simple procedures to get all the committed data in innodb binlog when it finishes the normal storage. Reading about MySQL Enterprise Backup also can do this.
Incremental backups/snapshots can be made with both Percona XtraBackup and MySQL Enterprise, if that's what you're looking for.
Using a read-only slave, you can maintain separation of the read locks. This will keep your locks from being held on the master read if you backup using mysql free tools.
Another option if you have a slave is you can shut off the slave and rsync the data somewhere for backup.
First I would try using "--single-transaction" with mysqldump as long as all your tables are innodb and you aren't modifying table structure during dump. This will attempt to dump from a single point in time but only when it can be performed without locking your tables.
I haven't tried xtrabackup but it looks like that will do what you want as well.
You could also try setting up mysql replication and dumping from the slave.
Lastly LVM snapshots but that takes a bit more work.
I have a couple of live databases that need migrating over to a new server. These are large databases constantly in use.
I want to setup replication with a slave on the new server and begin porting data across. However, I'd like to try and avoid doing a mysqldump on the current master data to get the initial binlog position as I don't want to lock down the database for an extended period of time.
Is there a way that I can find out the earliest master_log_pos so I can start replication from the very start? If not, are there any other solutions that avoid halting transactions (as much as possible)?
If I understand you correctly, I think Percona's Xtrabackup is helpful for you.
Xtrabackup is hot backup tool which makes you can backup MySQL while it is running.
With Xtrabackup you can make data backup quickly even if data is large and move backups to slaves.
How to setup a slave for replication in 6 simple steps with Percona XtraBackup is good start point.
http://www.percona.com/doc/percona-xtrabackup/2.1/ is Xtrabackup documentation
Setting up Master-Slave replication using xtrabackup also describes how to use it for making slave.
We are building a production setup which has two application servers and two mysql database servers. For HA capabilities I want to set up replication between the 2 database servers.
Some of the questions I want to address is:
1. What are the pros and cons of having a Master-Slave set up vs a Master-Master set up? Under what conditions do you pick one over the other?
2. In case of failure, which set up is a) Easy to perform failover and restore, b) More reliable (no data loss)?
I understand that Mysql provides binary replication, but I will have to use 3rd party tools like MMM (Multi-Master replication manager), I case of Master-Master set up, and Virtual IP's to handle failover.
Most of the docs I found on dev.mysql.com were related to setting up replication and does not really talk about the pros and cons on how to make a design decision between Master-Slave vs Master-Master setup.
Thank you.
I currently have a bunch of slaves set up with binary replication with one master and many slaves. It was a little easier to set up (pro), but requires more intervention if the master goes down. Master-master will rebuild itself if set up properly. Master-slave means the dba has to create a dump, move it back to the master, rebuild and restart MySql. Kind of a pain in the neck.
Basically Master-Master is way more robust if implemented properly. Implement it wrong and you can be in hot water. In small environments, the overhead of doing a manual rebuild on a master-slave can be small enough to not even warrant the more complicated master-master setup.