DOCUMENTATION ON MASTER-SLAVE

REPLICATION WITH POSTGRESQL AND THE

FUSIONPBX SERVICE

Introduction
Postgresql is what is called an RDBMS (relational data management system) and it is used in
many areas, including:
• Web and mobile applications requiring a robust database
• Geographic information systems (GIS) using the PostGIS extension
• Data warehouses and complex analytics
• Scientific and research applications
• Content management systems (CMS)
You should know that FusionPBX uses Postgresql to store its data and as its data is very
important for businesses, it is important not to lose it in the event of a server crash, which is
why we are going to use Master-Slave replication which allows a server or a group of servers
to be able to store the data of the master server without having the right to write on the data
which we will do below.
Requirements
• Install fusionpbx
• Install Postgresql version 16.3
It is possible to install them both via these commands:
• wget -O - https://raw.githubusercontent.com/fusionpbx/fusionpbx-
install.sh/master/debian/pre-install.sh | sh; (1)
• cd /usr/src/fusionpbx-install.sh/debian && ./install.sh (1)

After running these commands you will see at the end you will see this image
You must copy the password of the two machines the master and the slave where you installed
the service and keep them somewhere, because it is thanks to this that you will be able to
connect to the web interface of the FusionPBX service as you can see it in the following photo

Then restart the machines and then you can connect to the web interface via your browser. The
postgresql service is already installed so you can start working with the service.

Replication

On the Master server

Step 1: You can start by editing the postgresql.conf file via the nano or vi, vim command as
follows:
nano /etc/postgresql/16/main/posgresql.conf
Or
vi /etc/postgresql/16/main/posgresql.conf
Or
vim /etc/postgresql/16/main/posgresql.conf
and in the file you will modify the line listen_addresses replace the line
#listen_addresses=’localhost’
listen_addresses =’*’
As shown in the following image:
This will allow the master to listen to any IP address of servers that can be used for replication.

Step 2: You will then connect to the postgresql database via the command:

Then you will create a user and give him the replication role and a password and it is through
this user that the replication can be done; You will then type the following command:
CREATE USER replication WITH REPLICATION ENCRYPTED PASSWORD
‘MON_PASSWORD’;
N.B: the name of the user can change it could well be your first name or something else the
same for the password in all cases they must be kept secret by the administrator especially the
password to prevent the sensitive company data is replicated on a pirate server.
We should have this:

Step 3: Subsequently you must edit another conf file but it will be pg_hba.conf which allows
you to define the authentication rules for incoming connections to the PostgreSQL server
To do this you will need to add a line to this file and it is the following.
The boxed area is the line that will need to be added and the deleted area is the IP address of
the slave and this is how you will fill out the pg_hba.conf file.
Step 4: Subsequently for all the modifications to be taken into account by the service you will
have to restart the postgresql service of the master with the command
systemctl stop postgresql.service
Note: You are finished with the master if the service does not restart this will mean that you
have done one in the configuration of the postgresql.conf file, check again if step 1 was correctly
executed, the same goes for step 2 with the file pg_hba.conf.
On the Slave server
Step 5: Stop the postgresql service using the command
systemctl stop postgresql
Step 6: Delete the main folder of the postgresql service this folder contains all the files and
directories necessary for the operation of a PostgreSQL cluster, such as table data files, indexes,
transaction logs, etc. and it is necessary to delete it because the slave server will receive the
main folder from the master to ensure the proper functioning of the cluster
rm -rf /var/lib/postgresql/16/main/*
Step 7: Now run the pg_basebackup command which allows you to initialize a PostgreSQL
slave server by creating an online backup of the master server, while configuring continuous
replication via streaming transaction logs, type the command
pg_basebackup -h <master-ip> -D /var/lib/postgresql/16/main/ -U replication -P -v -R -X
stream -C -S slaveslot1

Explanation:
1. pg_basebackup: This is a PostgreSQL command that allows you to create an online backup
(hot backup) of a master server to initialize a slave server.
2. -h <master-ip>: Specifies the IP address or hostname of the PostgreSQL master server to
connect to.
3. -D /var/lib/postgresql/16/main/: Indicates the target directory where to store the backup files.
In this example, it is the main folder of the PostgreSQL version 16 cluster.
4. -U replication: Specifies the name of the PostgreSQL user to use for the connection. Here
the replication user is used, which must have the necessary rights for replication.
5. -P: Enables display of backup progress.
6. -v: Enables verbose mode for more details about command execution.
7. -R: Automatically generates a recovery.conf script in the target directory to configure the
slave server.
8. -X stream: Enables continuous backup of transaction logs (WAL) via streaming. This keeps
the slave server synchronized with the master in real time.
9. -C: Creates a replication slot on the master server. This reserves the transaction logs needed
for replication.
10. -S slaveslot1: Specifies the name of the replication slot to create on the master server. Here,
the slot is called slaveslot1.
Then you will get this result

The “Password” is the one that you created with your user in step 2 and you will see that it is
thanks to this user that the replication took place and it is also thanks to his role that we
attributed to him.
Step 8: Connect to your postgresql database via the commands from step 2 and you should get
this error

In fact the new main file that the slave has recovered does not have the necessary rights to be
taken into account by the service, this must be resolved using the chown command.

Note: Create a database via sql create database command and you should get this error

This is a sign that you have succeeded because the slave server does not have write permission.

Step 9: Connect to the web interfaces of the fusionpbx service for the master you will be able
to do it without problem but for the slave you will see this error
It's just an authentication problem because the fusionpbx database of the master and that of the
slave are different and this is not normal when we are talking about a cluster, which is why we
will have to copy the word password of the master's fusionpbx database and replace that of the
slave's database with the latter. To access the file which holds the database password, do:
nano /etc/fusionpbx/config.conf

systemctl restart freeswitch.service

And normally you should have the interface which opens and finally know that the password
of the slave will now be the same as that of the master so once in the interface you identify
yourself but you use the password of the master to identify you; the passwords are the ones you
saw copied just after installation and they are not the same as those in the fusionpbx database.
Here you have carried out a Master-Slave replication and normally when you want to work on
the slave and you want to register a user via the fusionpbx service you will get the following
error

Now if the Master server breaks down we will certainly have the data stored by the latter on the
slave but we will not have write rights and this will be problematic because if we want to add
another user via the service this will not be possible. will not work because we will not be able
to write to the database. To overcome this you will have to delete the file named
“standby.signal” it is this which gives the slave server only reading rights and that is why you
must carry out the following command:
rm -rf /var/lib/postgresql/16/main/standby.signal
This will desynchronize the two servers and the slave will once again have write rights to the
database that it had previously retained. Subsequently we can resynchronize them but it will be
the old master which will become the slave because the database has been modified in the
meantime so it will be necessary to repeat all the steps that we saw above.
REFERENCES

(1) https://dialer.one/how-to-install-fusionpbx-on-debian-12/

https://docs.postgresql.fr/16/