Avaya Callback Assist Application Notes for PostgreSQL Replication

Transcription

1 Avaya Callback Assist Application Notes for PostgreSQL Replication Release July 2018

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

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

4 Table of Contents Table of Contents Introduction... 5 System requirements... 7 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 Notes on Avaya Linux (Optional) Validating that Replication is working properly (Optional) Enabling Synchronous replication Failing Over to the Standby CBA Application Server(s) Database IP Address Change Making the original Master the Standby Making the original Master Master again Glossary CBA Application Notes for PostgreSQL Replication July

5 Introduction 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 transaction log 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 July

6 Introduction For more information on PostgreSQL replication schemes, see: CBA Application Notes for PostgreSQL Replication July

7 System requirements 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 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 or higher version. To use this new feature the existing users are required to upgrade CBA 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 to 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 July

8 Installation and configuration Installation and configuration Equipment and Software used for this document Component Version Avaya Callback Assist 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: Stand-By 1: Stand-By 2: Install PostgreSQL on each server Perform the tasks to install PostgreSQL on each Linux server(s) as mentioned in the Installing CBA section, PostgreSQL Database Server 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 July

9 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 July

10 Installation and configuration Run the Replication Script on Master server NOTES: 1. Before running the replication script make sure all the CBA Application server(s) are stopped. 2. If you are planning to do Database Tuning, make sure if you have already done. 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 makes sure the remote server(s) are able to reach using ping command [ping hostname]. Notes on Avaya Linux If you are installing CBA on Avaya Enterprise Linux for Avaya Aura Experience Portal 7.1 (aka Avaya Linux ), you will need to enable root login via ssh in the Standby server before running the setupreplication.sh, as follows: 1. Login to the remote machine ( ) with craft and then su sroot 2. vi /etc/ssh/sshd_config and change the following: a. comment the line DenyGroups root (# DenyGroups root) b. change PermitRootLogin no to PermitRootLogin yes 3. execute service sshd restart to read changed configuration 4. execute setupreplication.sh from the local machine, now it should work. Revert the above changes after setting up the replication and execute service sshd restart again. Perform the following tasks to setup the replication. 5. On the Master command line, go to support folder of installation directory: cd /opt/avaya/callbackassist/support (this is default installation directory) 6. 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. 7. 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 Enter the IP address or the host name of the Stand-By Database Server at the prompt. CBA Application Notes for PostgreSQL Replication July

11 Installation and configuration 9. Enter yes to confirm the IP address or the host name you entered in the previous step. 10. If the stand-by server(s) count is more than 1 then it will ask all the stand-by server details one by one. 11. 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. 12. It will start configuring replication setup for each stand-by server(s) one by one. 13. Enter the remote (stand-by database) server s root password. This is to connect the remote machine for several times during the setup and start the stand-by database automatically. Repeat this step for the remaining stand-by server(s) if any. 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 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 Is this correct? (Yes/No) Yes (03:33:17) Local Ip Address (Master DB): (03:33:17) Removing recovery.done file if it exists (03:33:17) Done. CBA Application Notes for PostgreSQL Replication July

12 Installation and configuration (03:33:17) Checking the Replication User (callback_rep) is exists on (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. (03:33:21) Allow Stand-By Database server(s) connect to Master DB ( ) (03:33:21) Done. (03:33:21) Configure Streaming Replication on Master DB ( ) (03:33:21) Done. (03:33:21) Restarting Master DB (03:33:23) Done. Replication Steps for Stand-By Server CBA Application Notes for PostgreSQL Replication July

13 Installation and configuration Generates, manages and converts authentication keys via SSH KEYGEN command. This is to avoid prompting password for accessing server during the entire process. Accept the connection request (if requires) for the remote server Provide root password for one time (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. (03:34:31) Copy Master DB ( ) data to Stand-by DB ( ) pg_start_backup /1A (1 row) CBA Application Notes for PostgreSQL Replication July

14 Installation and configuration 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 /1A (1 row) (03:34:32) Copying data from Master DB to Stand-by DB - Completed. (03:34:32) Starting Postgresql Service on Server: (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 (' :34:33') to test table... (03:34:33) Data inserted successfully. (03:34:33) Wait for 5 seconds to setup the replication and validate... (03:34:38) Checking the replication data (' :34:33') exists on (03:34:38) Replication data (' :34:33') exists. (03:34:38) INFO: Replication validation successful. (03:34:39) [ Replication process completed for Stand-By Server ] CBA Application Notes for PostgreSQL Replication July

15 Installation and configuration Replication Steps for Stand-By Server Generates, manages and converts authentication keys via SSH KEYGEN command. This is to avoid prompting password for accessing server during the entire process. Accept the connection request (if requires) for the remote server Provide root password for one time (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 July

16 Installation and configuration (03:44:11) Changing file permission and owner (03:34:57) Done. (03:34:57) Copy Master DB ( ) data to Stand-by DB ( ) pg_start_backup /1C (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 /1C0000F0 (1 row) (03:34:58) Copying data from Master DB to Stand-by DB - Completed. (03:34:58) Starting Postgresql Service on Server: (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 (' :35:21') to test table... CBA Application Notes for PostgreSQL Replication July

17 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 (' :35:21') exists on (03:35:26) Replication data (' :35:21') exists. (03:35:26) INFO: Replication validation successful. (03:35:27) [ Replication process completed for Stand-By Server ] CBA Application Notes for PostgreSQL Replication July

18 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 :19? 00:00:00 postgres: wal sender process callback_rep (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 :20? 00:00:00 postgres: wal receiver process streaming 0/1E2A7A90 3. Check the Stand-By /data/pg_log/ postgresql-<date>.log for a log line like the following: :10:00 UTC LOG: started streaming WAL from primary at 0/1B on timeline :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 test (test varchar(30)); CREATE TABLE template1=> INSERT INTO test VALUES ('Test Replication'); INSERT 0 1 template1=> select * from test; CBA Application Notes for PostgreSQL Replication July

19 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 test; 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 only be done when there's 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 Stand-By command line, go to PostgreSQL data directory: cd /opt/avaya/callbackassist/postgresql/9.4/data 2. Open postgresql.conf file: vi postgresql.conf synchronous_standby_names = '*' Where the value is a comma-separated list of your standby servers, it can be 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. 3. Save the changes by entering: Escape + wq! 4. Restart Master service by: /sbin/service cba-postgresql restart CBA Application Notes for PostgreSQL Replication July

20 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://<db-ip-address>: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 CBA Application Notes for PostgreSQL Replication July

21 Glossary 3. This script will ask the Master DB IP Address and it will change all the database configuration files. 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: A B (master) After: A (standby) B (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. CBA Application Notes for PostgreSQL Replication July

22 Glossary 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 (standby) B (master) After: A (master) B (standby) 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 July

23 Glossary Glossary For more information, see the following: CBA Application Notes for PostgreSQL Replication July