I've just setup MariaDB on Ubuntu VMs with Master-Master replication using a combination of these three guides:
http://www.chriscouture.com/setting-up-replication-on-mariadb/
https://www.server-world.info/en/note?os=Ubuntu_16.04&p=mariadb&f=3
https://www.digitalocean.com/community/tutorials/how-to-set-up-mysql-master-master-replication
In short, both are masters and both are slaves to the other one. This will be used by separate web hosting servers. One will be "primary master" which all web servers connect to, and in case of a failure on that server they will be manually changed to the "secondary master".
The reason I went for this instead of Master-Slave is
The 3rd party backup job is simpler. Both backups and restores are done on the "secondary" master, instead of backup from the secondary and restoring to the primary.
If the primary fails and I have to switch to the secondary for a while, all changes made during that time should be written to the primary when it comes online again (?).
It's not live yet but everything works fine so far when I'm testing it. However I'm no DBA. I've been reading about how it's not "worth it" and if you don't absolutely need the Master-Master you should go with Master-Slave.
Now I'm afraid I will run into problems like inconsistencies and other headaches.
A maximum of about 100 databases for mostly Wordpress installations will be hosted.
What are your thoughts on the matter? M-M or M-S?
If M-S, how do I "sync back" data changed if the Master goes down and the Slave need to be the active server for a period of time?
I'm also wondering if there's a standard, generally accepted, step-by-step way to upgrade these. I'm thinking when a OS or MariaDB version upgrade is needed.
My general thoughts are something like take down one server, upgrade it, start it. Then take down the other, upgrade it, start it.
But I'm guessing there's more to it than that.
I only found some documentation on M-S upgrading with Mysql.
Related
My company uses a product that uses MySQL 5.5 for its backend database. The product automatically installs and configures MySQL during it's installation process. The product can be configured to run in a Hot Standby Redundant configuration. In these cases, the same installation process is performed on 2 separate servers and then during the products initial configuration redundant mode is selected. The product internally handles all the processes of duplicating the database data and keeping the 2 databases in sync. MySQL has know knowledge of the redundant setup. The MySQL installation on both server are identical, same location and same structure. The product does not have a very elegant/efficient way to sync a large, say 300G is size with 3K tables, database from the Primary server to the Backup server in cases where this is required, such as when creating a redundant system from a Single/Primary server config that has already been running for a while. My question is as follows.
Is there a safe/supported way to just manually copy the database/files from the Primary server to the Backup server considering that the MySQL installation on both servers are identical? BTW, this is on Production Windows Servers. I know I can do a full Export of the database from the Primary and then Import it on the BU server, but this can take hours. I am hoping there is a faster supported way to just copy the files from one server to the other, but in researching this I see conflicting info.
System Info
Windows
MySQL 5.5
Identical installation on both servers
"C:\ProgramData\MySQL\MySQL Server 5.5\data"
Innodb
File per table = true
Thanks in advance for any advice.
I once tried to just copy the Database Folder that contains all the innodb table files, "C:\ProgramData\MySQL\MySQL Server 5.5\data\Mydbase", from one server to another but mysql would not start up and had errors.
Yes: shut down the MySQL Server service on both computers. Then you can move the files in the datadir in any way you want. But this incurs some downtime while you do the file transfer.
If you must have no downtime, it's also possible, but requires more steps.
What I do is use Percona XtraBackup to make a physical backup of the source instance, but this won't work as easily for you because you are on Windows. XtraBackup doesn't work on Windows. Some people use tricks to run XtraBackup in a Docker container on Windows.
Then restore the XtraBackup to your new computer in the normal way, and configure it as a replica of the source instance. See https://docs.percona.com/percona-xtrabackup/8.0/howtos/setting_up_replication.html
By making the new instance a replica, you can let it get updated with the most recent changes that have occurred on the source instance while you were setting up the replica.
Then at some point you decide to switch to the new instance. Then you set the source instance to read-only mode, to prevent client applications from making any new changes. Let the replica catch up with the last final changes (this should only take a second if the replica was keeping up with changes already). Now you can change your client applications to use the replica instead of the former source. Then un-configure replication on the new instance with RESET SLAVE because the last thing you want is for any more changes to occur on the former source and replicate to the new instance.
If you try this procedure, I suggest you test it on a test instance — NOT your production instance — until you are comfortable with the tools.
P.S.: In addition to not supporting Windows, I have no idea if the current version of XtraBackup works with MySQL 5.5. That version was released in 2010, and reached its end of life in 2018. So I think you will need to research which version of XtraBackup still can read a MySQL 5.5 instance. You might have to use an old version of XtraBackup.
Please forgive my ignorance but I do not have a ton of experience with MySQL. I am a web developer but overall I have pretty much just installed MySQL or spun up an RDS instance, connected to it and everything just works. However I am currently being tasked with creating a complete backup of our primary server (essentially high availability with a load balancer etc). So I thought now might be a good time to change how I haver our MySQL setup to take advantage of having 2 servers. Currently our MySQL lives on our primary servers and that will probably stay that way for now, however my goal with this new setup is to have 2 identical servers, both running the application and both having the exact same MySQL data structure / data. I want to be able to essentially open up the web application on one server, make a change, see it on the other or vica versa.
From my research it looks like what I want is called "Master-Master Replication" however it seems as if this is an older / more outdated approach? Every article I read is from ~2010-2012 and most people say it is depreciated and I should use Percona XtraDB Cluster, MySQL Group Replication, or Galera Cluster etc. I basically have no idea what any of that means and I am looking for the easiest way to get Master-Master type setup working. On top of that even if I wanted to use regular Master-Master replication it seems as if this is something specific to MySQL and not Percona which is what I actually use.
I know plenty about dev ops and can get everything but the MySQL up and running in no time but I would love some insight on the best way to do this. Currently servers are running Centos 7, Percona 5.7, Apache 2.4.
The easiest way to start is to setup a percona xtradb cluster with proxysql.
Percona xtradb cluster handles all the problems that are present in basic MySQL Master-Master Replication.
Both Galera and Percona Xtradb CLuster are same, as they use the same galera plugin, Only that Percona has customized it and added some extra features like in built proxysql( kind of load balancer for database).
Let's clear up one thing first. Percona is MySQL. If a feature is available on Oracle MySQL (the community version is what I am referring to here), then it is also available on Percona. Think of the two like a cake: MySQL is the base "cake" and Percona is the frosting/sprinkles/etc that go on top.
That being said you can absolutely do Master/Master using Percona MySQL. The standard/best practice is to configure this in active/hot-standby. Meaning, do not write to both nodes at the same time. Your application, or your middleware/proxy, must isolate writes to only one node. This will save you insane headaches when/if replication breaks.
ProxySQL is not a Percona product, but we do support it 100%. You can place ProxySQL in front of your M/M and setup the correct query rules to only route to one MySQL.
You are correct that the most modern solution here, and in my opinion, an easier solution, is to set up a 3-node Percona XtraDB Cluster (PXC). Again, Galera MySQL is the "cake" and PXC is all the extras on top. Group Replication is pie (just to continue the analogy.)
We consider a 3-node PXC fronted with ProxySQL to be one of the best HA solutions out there for MySQL. It is still best practice to only write to one node, and utilize the other 2 for read-only queries. If the primary node goes down, each of the other two have an up-to-the-transaction copy of the data. Again, ProxySQL helps route the traffic if primary goes down.
Backups can be taken from any PXC node using Percona XtraBackup in a non-blocking/hot fashion.
We use mysql multi-source replication, analysts and developers works with the databases, it's a main task of server(cross-bases queries, etc). Mysql slave replicates data from about 10-15 servers, some of them is realy big (400gb, 500gb, 1.5tb). Slave host - ec2 r4.2xlarge. But have some problems, main of them - stability. Often there is an errors 1236, 1594. We fix one channel - another fails, sometimes it's critical.
Backups of most master databases are performed through ebs snapshot, where datadir located. But here another problem of mysql multi-source - work with backups, unlike multi instance replication, I can not just change datadir, where backup located.
I was trying to find a solution that at least partially solved the problems of stability and work with snapshots, but I found absolutely nothing.
Did I understand correctly that there is no support for multi-source replication in the aws-RDS?
Maybe there is a similar solution, or there is another approach to solving the problem (FEDERATED is bad variant). Thanks for any help and advices.
As Michael said, you shouldn't be encountering these errors. Multi source replication has quite stable now. I personally been using it for more than 2 years now. Yes I have faced some of issues like "slave trying to access binlogs that master has purged", but most of them were easy to sort out. I would recommend you to look at these replication topics:
Errant transactions
GTID hole : this was there because of bug
max allowed packet error
We fix one channel - another fails, sometimes it's critical.
make sure you're not touching GTID set for other channels.
Did I understand correctly that there is no support for multi-source
replication in the aws-RDS?
The feature still not available in any of AWS cloud services. https://forums.aws.amazon.com/thread.jspa?messageID=781416&tstart=0
Multi source replication is not supported in RDS , you can use AWS DMS for same purpose .
I am designing a data replication solution across timezones and have run into the issue where I can only run and old version of MySQL (5.6) in one location, whereas the other two have MariaDB 10.2.
Now, I have read the information about Replication Compatibility over at MariaDB. Clearly I can't use MariaDB as a master and MySQL as a slave.
Intermediate solution based on Bash scripts
Yet, I want to use my EU server as a master and that is running MariaDB. So I'm now contemplating a way around the limitation. So far I have come up with an intermediate data storage solution in the overseas server, where data is shuffled periodically using my own Bash data migration scripts over a low bandwidth link.
MariaDB is required in the primary location
I have to use MariaDB in my primary location because I'm using the ColumnStore database there. That is unconditional as part of the application design.
Does this situation ring a bell?
Do you have experience with similar situations and would you mind sharing some inspiration as for how you did it?
My best solution so far is with Bash scripts that are cronned, where MySQL data is dumped (mysqldump) and transferred over a low bandwidth link, then merged with the master (ColumnStore storage engine). I'm looking at a T+1 data lag between my primary location and the secondary location that is running MySQL.
Any high level design thoughts or shared experience is highly appreciated.
Best regards
I am looking at creating a high availability Wordpress installation across two servers with a load balancer to distribute the traffic between these servers, I intend to setup a LAMP stack on these two web servers and configure MySQL master master replication to ensure both servers have the same content similar to the setup at https://www.linode.com/docs/websites/cms/high-availability-wordpress
For anyone created a similar setup before, is there anything to watch out for? Will this work without there being differences in the database assuming both nodes are online? If one node goes down will this synchronise with the other master node successfully?
This is a pretty old post, but I've set up exactly this recently.
I do not recommend setting up WordPress with master-master replication. The nodes went out of sync multiple times and resulted in split-brain. We've reverted back to master-slave replication because of the instability of the setup.
I recently tried this and regret it. I realize your post is now almost 2 years old, but thought I should put in my 2 cents for anyone considering this approach. I recommend you go with MariaDB with MaxScale to separate the reads and writes, and go with master-slave configuration. I'm running into all sorts of deadlocks, and issues with this configuration. Currently using MariaDB with Galera, with HAProxy up front.