Avaya Callback Assist Application Notes for PostgreSQL Replication

Release 5.0.0.0

February 2020

Issue 1

© 2015-2020 Avaya Inc. Avaya grants You a license within the scope of the license types All Rights Reserved. described below, with the exception of Heritage Nortel Software, Notice for which the scope of the license is detailed below. Where the While reasonable efforts have been made to ensure that the order documentation does not expressly identify a license type, information in this document is complete and accurate at the the applicable license will be a Designated System License. The time of printing, Avaya assumes no liability for any errors. Avaya applicable number of licenses and units of capacity for which the reserves the right to make changes and corrections to the license is granted will be one (1), unless a different number of information in this document without the obligation to notify any licenses or units of capacity is specified in the documentation or person or organization of such changes. other materials available to You. “Software” means computer Documentation disclaimer programs in object code, provided by Avaya or an Avaya Channel “Documentation” means information published by Avaya in Partner, whether as stand-alone products, pre-installed on varying mediums which may include product information, hardware products, and any upgrades, updates, patches, bug operating instructions and performance specifications that Avaya fixes, or modified versions thereto. “Designated Processor” means may generally make available to users of its products and Hosted a single stand-alone computing device. “Server” means a Services. Documentation does not include marketing materials. Designated Processor that hosts a software application to be Avaya shall not be responsible for any modifications, additions, or accessed by multiple users. “Instance” means a single copy of the deletions to the original published version of documentation Software executing at a particular time: (i) on one physical unless such modifications, additions, or deletions were performed machine; or (ii) on one deployed software virtual machine (“VM”) by Avaya. End User agrees to indemnify and hold harmless Avaya, or similar deployment. Avaya's agents, servants and employees against all claims, License type(s) lawsuits, demands and judgments arising out of, or in connection Designated System(s) License (DS). End User may install and use with, subsequent modifications, additions or deletions to this each copy or an Instance of the Software only on a number of documentation, to the extent made by End User. Designated Processors up to the number indicated in the order. Link disclaimer Avaya may require the Designated Processor(s) to be identified in Avaya is not responsible for the contents or reliability of any the order by type, serial number, feature key, Instance, location linked websites referenced within this site or documentation or other specific designation, or to be provided by End User to provided by Avaya. Avaya is not responsible for the accuracy of Avaya through electronic means established by Avaya specifically any information, statement or content provided on these sites for this purpose. and does not necessarily endorse the products, services, or Copyright information described or offered within them. Avaya does not Except where expressly stated otherwise, no use should be made guarantee that these links will work all the time and has no of materials on this site, the Documentation, Software, Hosted control over the availability of the linked pages. Service, or hardware provided by Avaya. All content on this site, Warranty the documentation, Hosted Service, and the product provided by Avaya provides a limited warranty on Avaya hardware and Avaya including the selection, arrangement and design of the software. Refer to your sales agreement to establish the terms of content is owned either by Avaya or its licensors and is protected the limited warranty. In addition, Avaya’s standard warranty by copyright and other intellectual property laws including the sui language, as well as information regarding support for this generis rights relating to the protection of . You may not product while under warranty is available to Avaya customers and modify, copy, reproduce, republish, upload, post, transmit or other parties through the Avaya Support website: distribute in any way any content, in whole or in part, including http://support.avaya.com or such successor site as designated by any code and software unless expressly authorized by Avaya. Avaya. Please note that if You acquired the product(s) from an Unauthorized reproduction, transmission, dissemination, storage, authorized Avaya Channel Partner outside of the United States and or use without the express written consent of Avaya can be a and Canada, the warranty is provided to You by said Avaya criminal, as well as a civil offense under the applicable law. Channel Partner and not by Avaya. Third Party Components Licenses “Third Party Components” mean certain software programs or THE SOFTWARE LICENSE TERMS AVAILABLE ON THE AVAYA portions thereof included in the Software or Hosted Service may WEBSITE, HTTP://SUPPORT.AVAYA.COM/LICENSEINFO OR SUCH contain software (including open source software) distributed SUCCESSOR SITE AS DESIGNATED BY AVAYA, ARE APPLICABLE TO under third party agreements (“Third Party Components”), which ANYONE WHO DOWNLOADS, USES AND/OR INSTALLS AVAYA contain terms regarding the rights to use certain portions of the SOFTWARE, PURCHASED FROM AVAYA INC., ANY AVAYA Software (“Third Party Terms”). As required, information AFFILIATE, OR AN AVAYA CHANNEL PARTNER (AS APPLICABLE) regarding distributed Linux OS source code (for those products UNDER A COMMERCIAL AGREEMENT WITH AVAYA OR AN AVAYA that have distributed Linux OS source code) and identifying the CHANNEL PARTNER. UNLESS OTHERWISE AGREED TO BY AVAYA copyright holders of the Third Party Components and the Third IN WRITING, AVAYA DOES NOT EXTEND THIS LICENSE IF THE Party Terms that apply is available in the products, SOFTWARE WAS OBTAINED FROM ANYONE OTHER THAN AVAYA, Documentation or on Avaya’s website at: AN AVAYA AFFILIATE OR AN AVAYA CHANNEL PARTNER; AVAYA http://support.avaya.com/Copyright or such successor site as RESERVES THE RIGHT TO TAKE LEGAL ACTION AGAINST YOU AND designated by Avaya. You agree to the Third Party Terms for any ANYONE ELSE USING OR SELLING THE SOFTWARE WITHOUT A such Third Party Components. LICENSE. BY INSTALLING, DOWNLOADING OR USING THE THIS PRODUCT IS LICENSED UNDER THE AVC PATENT PORTFOLIO SOFTWARE, OR AUTHORIZING OTHERS TO DO SO, YOU, ON LICENSE FOR THE PERSONAL USE OF A CONSUMER OR OTHER BEHALF OF YOURSELF AND THE ENTITY FOR WHOM USES IN WHICH IT DOES NOT RECEIVE REMUNERATION TO (i) YOU ARE INSTALLING, DOWNLOADING OR USING THE SOFTWARE ENCODE VIDEO IN COMPLIANCE WITH THE AVC STANDARD (“AVC (HEREINAFTER REFERRED TO INTERCHANGEABLY AS “YOU” AND VIDEO”) AND/OR (ii) DECODE AVC VIDEO THAT WAS ENCODED BY “END USER”), AGREE TO THESE TERMS AND CONDITIONS AND A CONSUMER ENGAGED IN A PERSONAL ACTIVITY AND/OR WAS CREATE A BINDING CONTRACT BETWEEN YOU AND AVAYA INC. OBTAINED FROM A VIDEO PROVIDER LICENSED TO PROVIDE AVC OR THE APPLICABLE AVAYA AFFILIATE (“AVAYA”). VIDEO. NO LICENSE IS GRANTED OR SHALL BE IMPLIED FOR ANY CBA Application Notes for PostgreSQL Replication February 2020 2

OTHER USE. ADDITIONAL INFORMATION MAY BE OBTAINED For the most current versions of Documentation, see the Avaya FROM MPEG LA, L.L.C. SEE HTTP://WWW.MPEGLA.COM. Support website: http://support.avaya.com, or such successor site Note to Service Provider as designated by Avaya. The product or Hosted Service may use Third Party Components Contact Avaya Support subject to Third Party Terms that do not allow hosting and require See the Avaya Support website: http://support.avaya.com for a Service Provider to be independently licensed for such purpose. product or Hosted Service notices and articles, or to report a It is your responsibility to obtain such licensing. problem with your Avaya product or Hosted Service. For a list of Preventing Toll Fraud support telephone numbers and contact addresses, go to the “Toll Fraud” is the unauthorized use of your telecommunications Avaya Support website: http://support.avaya.com (or such system by an unauthorized party (for example, a person who is successor site as designated by Avaya), scroll to the bottom of the not a corporate employee, agent, subcontractor, or is not working page, and select Contact Avaya Support. on your company's behalf). Be aware that there can be a risk of Trademarks Toll Fraud associated with your system and that, if Toll Fraud The trademarks, logos and service marks (“Marks”) displayed in occurs, it can result in substantial additional charges for your this site, the Documentation, Hosted Service(s), and product(s) telecommunications services. provided by Avaya are the registered or unregistered Marks of Avaya Toll Fraud intervention Avaya, its affiliates, or other third parties. Users are not permitted If You suspect that You are being victimized by Toll Fraud and You to use such Marks without prior written consent from Avaya or need technical assistance or support, call Technical Service Center such third party which may own the Mark. Nothing contained in Toll Fraud Intervention Hotline at +1-800-643-2353 for the United this site, the Documentation, Hosted Service(s) and product(s) States and Canada. For additional support telephone numbers, should be construed as granting, by implication, estoppel, or see the Avaya Support website: http://support.avaya.com or such otherwise, any license or right in and to the Marks without the successor site as designated by Avaya. Suspected security express written permission of Avaya or the applicable third party. vulnerabilities with Avaya products should be reported to Avaya Avaya is a registered trademark of Avaya Inc. by sending mail to: [email protected]. All non-Avaya trademarks are the property of their respective Downloading Documentation owners. Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

CBA Application Notes for PostgreSQL Replication February 2020 3

Table of Contents

Table of Contents

Chapter 1: Introduction ...... 5 Chapter 2: System requirements ...... 7 Chapter 3: Installation and configuration ...... 8 Equipment and Software used for this document ...... 8 Identify Master and Stand-by servers ...... 8 Install PostgreSQL on each server ...... 8 Run the Replication Script on Master server ...... 10 (Optional) Validating that Replication is working properly ...... 17 (Optional) Enabling Synchronous replication ...... 18 Failing Over to the Standby ...... 20 CBA Application Server(s) IP Address Change ...... 20 Making the original Master the Standby ...... 21 Making the original Master Master again...... 21 Database replication and Data Migration Tool ...... 23 Chapter 4: Glossary ...... 23

CBA Application Notes for PostgreSQL Replication February 2020 4

Introduction

Chapter 1: Introduction

The Avaya Callback Assist Application Notes for PostgreSQL Replication describes the procedures required for configuring the PostgreSQL DB Replication. This document covers only PostgreSQL Streaming Replication scheme and does not provide any information on Write-Ahead log Archiving or any other thirty party tool.

PostgreSQL Replication is based on Write-Ahead log (WAL) files transfer between servers. This transfer could be made record to record (record-based log shipping) or complete stream of WAL file transfer, called file-based log shipping.

Streaming Replication allows a standby server to stay more up-to-date than is possible with file-based log shipping. The standby connects to PostgreSQL Replication the primary, which streams WAL records to the standby as they're generated, without waiting for the WAL file to be filled. Streaming replication is, by default, asynchronous, so there is still a small delay between committing a transaction in the primary server and for the changes to become visible in the standby. The delay is however much smaller than with file-based log shipping, typically under one second assuming the standby is powerful enough to keep up with the load. Synchronous replication offers the ability to confirm that all changes made by a transaction have been transferred to one synchronous standby server. This extends the standard level of durability offered by a transaction commit. Each commit of a write transaction will wait until confirmation is received that the commit has been written to the on disk of both the primary and standby server. Waiting for confirmation increases the user's confidence that the changes will not be lost in the event of server crashes but it also necessarily increases the response time for the requesting transaction.

The following image(s) illustrates the PostgreSQL replication scheme for Streaming Replication:

Figure 1: PostgreSQL replication scheme for Streaming Replication

CBA Application Notes for PostgreSQL Replication February 2020 5

Introduction

For more information on PostgreSQL replication schemes, see: http://www.postgresql.org/docs/9.4/static/high-availability.html

CBA Application Notes for PostgreSQL Replication February 2020 6

System requirements

Chapter 2: System requirements

The requirements to set up one Master and one or more Stand-By server(s) are as follows:

• Minimum Two Red Hat Linux Servers with same architecture (32 or 64 bits) • Callback Assist 4.3.3.0 or higher Installation file • All Linux servers should have ssh-keygen and rsync packages in order to connect the stand-by DB server(s) remotely and copy files from Master to Stand-by. • To successfully configure PostgreSQL replication, you must be logged in Linux as root. • Automated Replication script supported from CBA 4.3.3.0 or higher version. To use this new feature the existing users are required to upgrade CBA 4.3.3.0 or higher. Refer the “Installing and configuring Avaya Callback Assist” Guide section “Upgrading High Availability Deployment” for more details. • Failover decision to the standby PostgreSQL server will not be automatic and must be initiated manually.

Notes:

1. Starting from Callback Assist 4.3 PostgreSQL database version upgraded from 9.1.5 to 9.4.4. 2. For more information on the detailed requirements for RHEL Linux, see the Environment Configuration section in the Installing and configuring Avaya Callback Assist Guide.

CBA Application Notes for PostgreSQL Replication February 2020 7

Installation and configuration

Chapter 3: Installation and configuration

Equipment and Software used for this document

Component Version Avaya Callback Assist 4.3.3.0 Linux version RHEL RHEL 6.0 (Santiago) Server architecture 64 bits Server RAM Memory 8 GB Linux user root (both servers)

Identify Master and Stand-by servers

For the purpose of this document, those two servers will be identified with the following addresses:

• Master: 10.130.124.27 • Stand-By 1: 135.122.99.205 • Stand-By 2: 135.122.99.80

Install PostgreSQL on each server

Perform the tasks to install PostgreSQL on each Linux server(s) as mentioned in the Installing CBA section, PostgreSQL for Callback Assist option in the Installing and configuring Avaya Callback Assist guide.

The installation output will be similar to the following:

[root@denpsqassa4 r44394]# ./callback-install.sh

********************************************************** Avaya Callback Assist Installer **********************************************************

(12:38:51) [ No Callback Assist Components were found. ]

(12:38:51) Please choose the Components to be Installed on this server:

1) Callback Assist Components with external Database 2) PostgreSQL Database Server for Callback Assist

CBA Application Notes for PostgreSQL Replication February 2020 8

Installation and configuration

3) Callback Assist Components and PostgreSQL Database Server #? 2

(12:44:59) [ About to Install PostgreSQL Database Server for Callback Assist ]

Please, enter the base directory where Avaya Callback Assist will be installed (default directory /opt):

Directory where Avaya Callback Assist is going to be installed: /opt/Avaya/callbackassist

(12:45:17) Checking if there is enough disk space... (12:45:17) Available disk space is enough.

(12:45:17) Unpackaging distribution file callbackassist.package...

(12:45:25) Creating callback Group... (12:45:25) Creating callback User... (12:45:25) 32 bit Architecture detected ... (12:45:25) Using 32 bit PostgreSQL Installer... (12:45:25) Installing PostgreSQL Server, this step may take several minutes... (12:45:51) Creating 'callback' PostgreSQL user... (12:45:51) Creating 'callback' database... (12:45:52) 'callback' database created. server signaled (12:45:52) Signaling Postgresql postmaster... (12:45:52) Done. (12:45:52) Setting ownership to callback user.

(12:45:52) [ Installation of PostgreSQL Database Server for Callback Assist completed. ]

CBA Application Notes for PostgreSQL Replication February 2020 9

Installation and configuration

Run the Replication Script on Master server

NOTES:

1. Before running the replication script, please make sure that: a) PostgreSQL services are active and running on both Master and Slave Database servers, b) all the CBA Application server(s) are stopped and c) kafka-zookeeper and kafka services at Master Database server are not stopped. 2. If you are planning to do “”, please refer the section “Database Tuning” in “Installing and configuring Avaya Callback Assist” user guide. 3. If you are planning to use hostname in the input fields, make sure the hostname is a valid FQDN (Fully Qualified Domain Name) and properly configured in /etc/hosts file. Before running script make sure the remote server(s) are reachable using ping command [ping hostname].

Perform the following tasks to setup the replication.

1. On the Master Database server command line, go to support folder of installation directory: cd /opt/Avaya/callbackassist/support (this is default installation directory)

2. Run the replication setup script file: ./setupReplication.sh

The system writes the command output of the scripts to the standard output and to the replication-setup.log file in your system. Then the system prompts you for various parameters which is described in the next steps.

3. Select how many Stand-By database server(s) are you going to configure for replication. By default this will be only one, and maximum stand-by server(s) that can be setup as three. 4. Enter the IP address or the host name of the Stand-By Database Server at the prompt. 5. Enter yes to confirm the IP address or the host name you entered in the previous step. 6. If the stand-by server(s) count is more than 1 then it will ask all the stand-by server details one by one. 7. Enter the Replication user’s password. If it is first time then you can choose any password, if the replication setup is run for second time (ie., after the fail-over) you have to enter the existing Replication user’s password. 8. It will start configuring replication setup for each stand-by server(s) one by one. 9. After the ./setupReplication.sh script finishes its work, please restart callbackassist services at both CBA Application servers.

CBA Application Notes for PostgreSQL Replication February 2020 10

Installation and configuration

The following example shows the script output of the setupReplication.sh script:

[root@denpsqassa4 support]# ./setupReplication.sh

**********************************************************

Postgresql Database Replication Setup

**********************************************************

How many Stand-By Server(s) are you going to configure for replication [default: 1 maximum 3 allowed]: 2

(03:33:05) Please enter the Callback Assist Standby Database Server IP Address or Host name: (03:33:10)

You've entered 135.122.99.80. Is this correct? (Yes/No) Yes

(03:33:11) Please enter the Callback Assist Standby Database Server IP Address or Host name: (03:33:16)

You've entered 135.122.99.205. Is this correct? (Yes/No) Yes

(03:33:17) Local Ip Address (Master DB): 10.130.124.27

(03:33:17) Removing recovery.done file if it exists

(03:33:17) Done.

(03:33:17) Checking the Replication User (callback_rep) is exists on 10.130.124.27...

(03:33:17) Replication User (callback_rep) already exists

(03:33:17) Please provide the existing Replication User's (callback_rep) passoword:

(03:33:21) Done. CBA Application Notes for PostgreSQL Replication February 2020 11

Installation and configuration

(03:33:21) Allow Stand-By Database server(s) connect to Master DB (10.130.124.27)

(03:33:21) Done.

(03:33:21) Configure Streaming Replication on Master DB (10.130.124.27)

(03:33:21) Done.

(03:33:21) Restarting Master DB 10.130.124.27

(03:33:23) Done.

**********************************************************

Replication Steps for Stand-By Server 135.122.99.80

**********************************************************

(00:42:23) Stop the database and change to Stand-By Mode

(00:42:24) Done.

(00:42:24) Modifying config files

(00:42:24) Backing up the config files

(00:42:24) Removes the data folder

(00:42:24) Moving the config files to the original location

(00:42:24) Changing file permission and owner

(03:34:31) Done.

CBA Application Notes for PostgreSQL Replication February 2020 12

Installation and configuration

(03:34:31) Copy Master DB (10.130.124.27) data to Stand-by DB (135.122.99.80)

pg_start_backup

------

0/1A000060

(1 row)

NOTICE: WAL archiving is not enabled; you must ensure that all required WAL segments are copied through other means to complete the backup

pg_stop_backup

------

0/1A000128

(1 row)

(03:34:32) Copying data from Master DB to Stand-by DB - Completed.

(03:34:32) Starting Postgresql Service on Server: 135.122.99.80

(03:34:33) Done.

(03:34:33) Validating the Replication Setup

(03:34:33) Creating table for testing...

(03:34:33) test table successfully created.

(03:34:33) Inserting data ('2015-12-26 03:34:33') to test table...

(03:34:33) Data inserted successfully.

(03:34:33) Wait for 5 seconds to setup the replication and validate...

CBA Application Notes for PostgreSQL Replication February 2020 13

Installation and configuration

(03:34:38) Checking the replication data ('2015-12-26 03:34:33') exists on 135.122.99.80...

(03:34:38) Replication data ('2015-12-26 03:34:33') exists.

(03:34:38) INFO: Replication validation successful.

(03:34:39) [ Replication process completed for Stand-By Server 135.122.99.80 ]

**********************************************************

Replication Steps for Stand-By Server 135.122.99.205

**********************************************************

(03:44:10) Stop the database and change to Stand-By Mode

(03:44:11) Done.

(03:44:11) Modifying config files

(03:44:11) Backing up the config files

(03:44:11) Removes the data folder

(03:44:11) Moving the config files to the original location

CBA Application Notes for PostgreSQL Replication February 2020 14

Installation and configuration

(03:44:11) Changing file permission and owner

(03:34:57) Done.

(03:34:57) Copy Master DB (10.130.124.27) data to Stand-by DB (135.122.99.205)

pg_start_backup

------

0/1C000028

(1 row)

NOTICE: WAL archiving is not enabled; you must ensure that all required WAL segments are copied through other means to complete the backup

pg_stop_backup

------

0/1C0000F0

(1 row)

(03:34:58) Copying data from Master DB to Stand-by DB - Completed.

(03:34:58) Starting Postgresql Service on Server: 135.122.99.205

(03:35:21) Done.

(03:35:21) Validating the Replication Setup

(03:35:21) Creating table for testing...

(03:35:21) test table successfully created.

(03:35:21) Inserting data ('2015-12-26 03:35:21') to test table...

CBA Application Notes for PostgreSQL Replication February 2020 15

Installation and configuration

(03:35:21) Data inserted successfully.

(03:35:21) Wait for 30 seconds to setup the replication and validate...

(03:35:26) Checking the replication data ('2015-12-26 03:35:21') exists on 135.122.99.205...

(03:35:26) Replication data ('2015-12-26 03:35:21') exists.

(03:35:26) INFO: Replication validation successful.

(03:35:27) [ Replication process completed for Stand-By Server 135.122.99.205 ]

CBA Application Notes for PostgreSQL Replication February 2020 16

Enabling Synchronous replication

(Optional) Validating that Replication is working properly

In a high latency network (latency between Master DB to Stand-By DB is more than 280 ms) the replication validation check during the replication automation script may get failed. In order to validate the replication manually follow the steps.

The following tasks can be performed to validate that replication is working:

1. Check that the Master server is running the "sender" daemon: ps -fea | grep sender

[root@denpsqassa4 9.4]# ps -fea | grep sender

callback 30593 30585 0 12:19 ? 00:00:00 postgres: wal sender process callback_rep 135.122.99.206(38285) streaming 0/16E1C58

2. Check that the Stand-By is running the "receiver" daemon: ps -fea | grep receiver

[root@RHEL60EPAEP pg_log]# ps -fea | grep receiver

callback 31809 31804 0 14:20 ? 00:00:00 postgres: wal receiver process streaming 0/1E2A7A90

3. Check the Stand-By /data/pg_log/ -.log for a log line like the following:

2013-11-22 21:10:00 UTC LOG: started streaming WAL from primary at 0/1B000000 on timeline 5 2013-11-22 21:10:00 UTC LOG: database system is ready to accept read only connections

4. Insert data into Master database by running under bin directory: psql -p 6198 template1 -U callback_rep

Enter callback_rep password as requested.

template1=> CREATE TABLE test123 (test varchar(30));

CREATE TABLE

template1=> INSERT INTO test123 VALUES ('Test Replication');

INSERT 0 1

template1=> select * from test123;

CBA Application Notes for PostgreSQL Replication February 2020 17

Enabling Synchronous replication

test

------

Testing Replication

(1 row)

template1=>\q

5. Check that the same data exists on Stand-By server: psql -p 6198 template1 -U callback_rep

template1=> select * from test123;

test

------

Testing Replication

(1 row)

template1=>\q

(Optional) Enabling Synchronous replication Enabling Synchronous Replication just takes a couple of additional steps. Keep in mind though, that this should done only in case there is little latency between the Master and the Stand-by servers because each query/transaction on the Master will wait for a response from the Stand-by, which has to go over the network. Only configure synchronous replication if both the master and standby are connected over a local (preferably private) network.

1. Under Standby Database server command line, go to PostgreSQL data directory: cd /opt/Avaya/callbackassist/PostgreSQL/9.4/data

2. Open recovery.conf file: vi recovery.conf

3. You will see the following line: 'primary_conninfo = 'host=10.133.93.93 port=6198 user=callback_rep password=Avaya123$'

4. Edit it by adding application name you will use for standby server in the future: 'primary_conninfo = 'host=10.133.93.93 port=6198 user=callback_rep password=Avaya123$ application_name=standbydb'

CBA Application Notes for PostgreSQL Replication February 2020 18

Enabling Synchronous replication

5. Save the changes by entering: Escape + wq!

6. Restart the cba-postgresql service at Standby Database Server: service cba-postgresql restart

7. Under Master Database server command line, go to PostgreSQL data directory: cd /opt/Avaya/callbackassist/PostgreSQL/9.4/data

8. Open postgresql.conf file: vi postgresql.conf

#synchronous_standby_names = ''

Edit it in order to remove ‘#’ commentary sign and include Standby name.

synchronous_standby_names = 'standbydb'

Value can a comma-separated list of your standby servers, in case you are using more than one, but only the first one will be used. If for some reason the first one goes down, the second will become the standby.

9. Save the changes by entering: Escape + wq!

10. Restart the cba-postgresql service at Master Database Server: service cba-postgresql restart

CBA Application Notes for PostgreSQL Replication February 2020 19

Glossary

Failing Over to the Standby When the Master servers go down the Stand-by server can become active by simply creating a file already defined on recovery.conf. This file will tell PostgreSQL to change from hot_standby to normal operation.

1. To change the Standby server to become Active (ie.: stop stream from the Master and f), create the "trigger_file.log" file under the specified folder.

2. Once the Stand by become Active, you can see the recovery.conf file renamed to recovery.done. This is done by PostgreSQL to ensure that we do not accidentally re-enter archive standby mode.

3. Change the IP Address of the new database server (HOT) in all the CBA Application servers. Follow the steps mentioned below.

CBA Application Server(s) Database IP Address Change

NOTE:

Before running the Change Database URL script make sure all the CBA Application server(s) are stopped. Also make sure none of JAVA processes are running by executing the following command: ps –ef | grep java

If there are some JAVA process (CBA related) still running, wait for the process to finish or kill if required.

Whenever the database server changes, we need to inform to the CBA Application, for the new IP address change. Go to each CBA Application servers (HOT & STANDBY) and modify the following database URLs to point to the new Database IP Address: dbUrl=jdbc:postgresql://:6198/callback

1. On Primary CBA Application server stop the callbackassist service:

/sbin/service callbackassist stop

2. On the PrimaryM command line, go to support folder of installation directory and run the script file changeDatabaseUrl.sh: cd /opt/Avaya/callbackassist/support (this is default installation directory)

./ changeDatabaseUrl.sh

3. This script will ask the Master DB IP Address and it will change all the database configuration files. CBA Application Notes for PostgreSQL Replication February 2020 20

Glossary

4. Start the callbackassist service:

/sbin/service callbackassist start

5. Repeat the same procedure on the Stand-By CBA Application server.

Making the original Master the Standby Note: for clarity let’s suppose the original Master server is called A and the original Standby server is called B.

Before: B A (master)

After: A B (standby) (master)

Once the recovery.conf file is renamed to recovery.done in B during the steps “Failing Over to the Standby”, you can consider B the Master Database.

In order to make A (the original Master) the Standby server you have two options:

1. Without reinstalling the Callback Assist Database: follow the steps in “Run the Replication Script on Master server” in B that is now the Master server, to setup the replication again. This is the option you would choose if you decided to failover to B for example to perform maintenance tasks on A.

Important: When A servers comes back the service PostgreSQL should be stopped before you run the replication setup (setupReplication.sh) script.

2. Run the CBA installer in A to reinstall the PostgreSQL Database Server for Callback Assist, and then follow the steps in “Run the Replication Script on Master server” in B that is now the Master server, to setup the replication again.

Making the original Master Master again Note: for clarity let’s suppose the original Master server is called A and the original Standby server is called B.

Before: A B (standby) (master)

CBA Application Notes for PostgreSQL Replication February 2020 21

A B (master) (standby) Glossary

After:

If server B is the Master and A is the Standby (ie.: A is replicating successfully from B, meaning A’s database is up-to-date with B’s database), and you want sever A to become the Master again, you need to perform the following steps:

1. Stop PostgreSQL server in server B. 2. Follow the steps in “Failing Over to the Standby” to make A the Master again. 3. Follow the steps in “Run the Replication Script on Master server” in A. 4. Point the CBA Application Servers (Primary and Secondary) to the new Master A, by following the steps in “CBA Application Server(s) Database IP Address Change”.

CBA Application Notes for PostgreSQL Replication February 2020 22

Glossary

Database replication and Data Migration Tool Note: In case you’re migrating from CBA 4.7.1.x to 5.0.0.x using CBA Data Migration Tool (please refer to the Chapter 17 of Installing and configuring Avaya Callback Assist guide for further information about Data Migration Tool and data migration process) and you’ve already set up the database replication at CBA 5.0.0.x, then this replication link will be broken after the replication ends.

So, after the replication ends, please run Replication Script again, as described above.

This is only about possibly existing replication at CBA 5.0.0.x system. Your existing CBA 4.7.1.x replication will not be harmed in any way.

However, we do not recommend enabling database replication at TARGET migration machine before performing the data migration. Please enable it later, after the data migration ends.

Chapter 4: Glossary

For more information, see the following:

• http://www.postgresql.org/docs/9.4/static/high-availability.html • http://wiki.postgresql.org/wiki/Binary_Replication_Tutorial

CBA Application Notes for PostgreSQL Replication February 2020 23