In today’s fast-paced digital world, data synchronization between servers is a crucial component of maintaining data integrity and availability. Whether you’re managing a web application, a database cluster, or simply need to ensure data redundancy, having a reliable solution for data synchronization is essential. One such solution that stands out is Lsyncd.

What is Lsyncd

Lsyncd, short for “Live Syncing Daemon,” is an open-source tool designed to facilitate real-time file synchronization between two or more servers. It leverages the inotify system to monitor file system events and initiates data transfers whenever changes occur in specified directories. This makes Lsyncd an excellent choice for maintaining consistent data across multiple servers and ensuring high availability.

Configuration of Servers for Data Synchronization

Before deep dive into Lsyncd’s configuration, it’s important to understand the basic setup of the servers involved in data synchronization. Typically, you will have two servers.

1. Source Server: This is the server that contains the original data or files you want to sync. Changes made on this server trigger synchronization to the destination server(s).

2. Destination Server(s): These are the servers where you want to replicate the data from the source server. Changes on the source server are propagated to the destination server(s) to keep them up to date.

1. Installation

1
2
3
4
5
6
7
8
9
# rync is required for lsyncd to work
yum install rsync

# install lsyncd
yum install epel-release
yum install lsyncd

# confirm the installation version
lsyncd --version

2. Configuration for one-way Synchronization (Source)

One-way synchronization, often referred to as “master-slave” or “primary-secondary” synchronization, is the most common use case for Lsyncd. In this configuration, changes made on the source server are mirrored to one or more destination servers.

Configuration file lsyncd.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
settings {
    logfile = "/var/log/lsyncd/lsyncd.log",
    statusFile = "/var/run/lsyncd/lsyncd.status"
}

sync {
    default.rsyncssh,
    source = /var/www/html/upload,
    host = lsync@192.168.0.2,
    targetdir = /var/www/html/upload,

    rsync = {
        archive = true,
        compress = true,
        verbose = true
    }
}

3. SSH configuration (Source)

To accomplish a remote synchronization using Lsyncd, the source server must have password less SSH access to the target server. This is done by creating SSH keys in the source server.

1
2
# generate keys for the user lsync used in the config file
ssh-keygen -t rsa

4. SSH configuration (Source)

Now that the keys are generated, copy the key to the destination server. To copy it into the authorized_keys file in the destination server, use the following instruction on the source server where the keys have been generated

1
2
3
4
5
6
# copy the key file of the lsync user to the destination server
sudo su
ssh-copy-id lsync@192.168.0.2

# test if password less SSH is working, If you are able to log without being prompted for a password, the process has succeeded.
ssh 192.168.0.2

Make sure to create the same user lsync on the destination server before trying Point No. 4. Additionally you may need to create .ssh directory in the user home directory /home/lsync.

5. Modify permissions for the user

To give the lsync user read and write permissions to the directory /var/www/html, you need to change the ownership and/or permissions of that directory.

1. If the directory is a location where the lsync user don’t have access you can change ownership.

1
sudo chown -R lsync:lsync /var/www/html

1. If the owener of the directory is owned by apache group, while keeping the current ownership, you can modify the permissions of the directory.

1
2
sudo usermod -a -G apache lsync
sudo chmod -R g+rw /var/www/html

6. Start the service (Source)

Start the Lsyncd service, and it will continuously monitor changes in the source and replicate them to the destination.

1
2
# start the service
systemctl start lsyncd

One-way synchronization is suitable for scenarios where you have a primary server with critical data, and you want to ensure that data is replicated to one or more backup servers for redundancy and disaster recovery.