1

Now, I know there are plenty of solutions around, and plenty of answers to this sort of question, however I'm yet to find something that I can use properly use.

So my server setup is basically three clusters, each cluster containing four servers. Three servers are master servers and one is a backup server. There's also the "front facing" servers which don't store any user data, but provides the rest of the site content. Oh and a database server. All of these run on CentOS 7

I need a way of synchronising all three of the master servers (leaving the backup server alone).

Most of the master-master replication tools I've found so far don't seem to work the way I intend them too, but I know there's a solution somewhere.

The application is designed to designate a master server to each user, based on average load at the time of sign up. So whilst all three servers in each cluster are master servers, they also act partially as slaves, however they can step in as masters should the usual server of a user be under high load or offline.

If I recall correctly, some sync software runs on one central server that doesn't hold any data. I can add another server to each cluster to be the "central server" should I need.

The other idea I had was to store user changes in a database then use that to transfer to other servers, but I feel like this would result in conflicts too often

2 Answers 2

1

Your question is perhaps a little sparse on the details - exacly what kind of files do you want to synchronize and how often do they need to be brought in sync for example?

I any case, I have had some success in syncing mirrors of file collections (it sounds to me like this is more or less what you want) using Unison. You can get precompiled versions here. I like it because it works reasonably well across different platforms but again, your setup might not warrant the use of Unison. Maybe you should use a distributed file system instead - GlusterFS helps here.

1
  • GlusterFS seems to be the way to go, I'll be setting that up straight away, cheers Feb 29, 2016 at 13:39
1

The problem with sync solutions is the interval between updates.
You can use DRBD to implement a RAID over TCP/IP and connect your master servers to this resource. Others solutions could be shared disk filesystems (like ATA_over_Ethernet) or the distributed filesystems (like Ceph).

2
  • DRBD was one solution I had already been looking at. It seems to cover the basis of what I want - which is to be able to sync a selection of data across multiple servers. Each user is forced at application level to only be able to upload to one server at a time, no matter how many devices they are logged in with. This means write conflicts shouldn't ever happen no matter what. The thing is, if someone were to write to one server, then 30 minutes later, write to another, then another 3 minutes later, delete from another, would DRBD reflect those changes across all servers? Feb 29, 2016 at 13:23
  • Mmm.... DRBD's aim is to keep sync data between masters and slaves. If you want to access at the same time, then you must use something like Ceph or GlusterFS. Red Hat suggests Ceph is better for OpenStack and Gluster for Big Data analytics. Mar 1, 2016 at 17:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .