Database Manager for PostgreSQL 9.1 (v13 Infinity) - Runbook
Table of Contents
-
Common Operational Tasks
- Create a Primary Backup
- Create a Secondary Backup
- Intialize a Slave Database Server
- Enable Continuous Primary Backups or Change the Primary Backup Policy
- Disable Continuous Primary Backups
- Restore a Database from a Primary Backup
- Restore a Database from a Secondary Backup
- Reset the Database Server
- Promote Slave to Master
- Terminate Database Servers
- Register Slave Server with DNS
- Grow the Size of the Database
- Add or Remove a Firewall Rule
- List Current Firewall Rules
- Show Replication Mode
- Set Asynchronous Replication to Sync Mode
- Set Synchronous Replication to Async Mode
- See also
After successfully setting up your PostgreSQL database server in the cloud using the Database Manager for PostgreSQL 9.1 Database Setup tutorial, you may need to perform the following common administrative operations.
NOTE: When performing the following operations, any inputs included in the block_device cookbook, if set or changed after the server launch, will not take effect until you manually run the block_device::default recipe (under "Boot Scripts") for the server. See RightScale Cookbook Design Conventions for more information.
Common Operational Tasks
Create a Primary Backup
Create a Secondary Backup
Intialize a Slave Database Server
Enable Continuous Primary Backups or Change the Primary Backup Policy
Disable Continuous Primary Backups
Restore a Database from a Primary Backup
Restore a Database from a Secondary Backup
Reset the Database Server
Promote Slave to Master
Terminate Database Servers
Register Slave Server with DNS
Add or Remove a Firewall Rule
When iptables is enabled, which is the default behavior in all Linux-based v13 ServerTemplates, TCP ports 22, 80, and 443 are configured to be open to any IP address in order to enable minimum functionality and access. If you want to add or remove a firewall rule on a running (operational) server by opening or closing a port, you can set the following inputs accordingly and run the sys_firewall::setup_rule operational script.
If you want the firewall rules to be set at boot time, you can either add the Chef recipe to the end of the boot script list or update the sys_firewall::default recipe to change the list of default firewall permissions by explicitly opening up additional ports. However, you should only consider overriding the default recipe if you want to change the default behavior for all of your servers that use that cookbook.
Note: If the cloud provider supports security groups, you must also open or close the appropriate ports in the security group resource.
- Go to the current server's Inputs tab and set the following inputs accordingly.
| Input Name | Description | Example Value |
| Firewall Rule Port | Specify the port number to open or close. | text: 8080 |
| Firewall Rule | Defines whether you are creating or removing a firewall permission for the specified port (Firewall Rule Port) over the specified IP protocol (Firewall Rule Protocol), as restricted by the specified IP range (Firewall Rule IP Address).
| text: enable |
| Firewall Rule IP Address | Use CIDR notation to define the range of IP addresses that will either be allowed or denied access to the specified port (Firewall Rule Port) over the specified IP protocol (Firewall Rule Protocol). Leave this value set to "any" (default) to allow access from any IP address (0.0.0.0/0). Use an exclamation point (!) before the IP address specification to deny access (i.e. "blacklist") from a specific IP address (e.g. !192.1.2.3) or IP range (e.g. !192.3.0.0/24) | text: any text: 192.1.2.0/24 |
| Firewall Rule Protocol | Specify the Internet protocol for the specified port (Firewall Rule Port).
| text: tcp |
- Run the sys_firewall::setup_rule operational script to add the firewall permission to the running server(s).
List Current Firewall Rules
For troubleshooting and security purposes, you may want to list a server's current firewall rules to make sure that a server has the expected IP/port permissions. This script is especially useful if you want to check the firewall rules across all servers in a deployment to validate that all of them have the same iptables rules.
- Go to the running server's Scripts tab and run the sys_firewall::do_list_rules operational script.
- Go to the server's Audit Entries tab to view the output. The output will look similar to the following example.
22:25:03: ==================== do_list_rules : Firewall rules Begin ================== Chain INPUT (policy ACCEPT) target prot opt source destination FWR all -- 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain FWR (1 references) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 ACCEPT tcp -- 10.123.456.22 0.0.0.0/0 tcp dpt:8000 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x16/0x02 reject-with icmp-port-unreachable REJECT udp -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable ==================== do_list_rules : Firewall rules End ====================
If you want to perform the same action via SSH, follow the steps below.
- SSH into the running server. (Requires 'server_login' user role privileges.)
- Switch to the 'root' user.
Note: When using newer images (>5.8/13.4), ensure that you have the 'server_superuser' permission to the Rightscale account where the server is running in order to gain root privileges using the sudo command (Settings > Account Settings > Users).
# sudo -i
- Type the following Unix command.
# /sbin/iptables -L
Show Replication Mode
Replication between master and slave database servers can be asynchronous (default) or synchronous. Run the following script to check the current replication mode.
- Go to the Scripts tab of the "master" database server and run the db_postgres::do_show_slave_sync_mode operational script. Note: The script cannot be successfully executed on a "slave" database server.
Set Asynchronous Replication to Sync Mode
By default, data is replicated between master and slave database servers asynchronously, however it can be changed to synchronous mode, if preferred.
Important! Before changing the database replication mode, please read PostgreSQL documentation on Synchronous Replication.
- (Optional) Before you change the database replication mode, you may want to check the current replication mode. See Show Replication Mode.
- Go to the Scripts tab of the "master" database server and run the db_postgres::do_set_slave_sync_mode operational script. Note: The script cannot be successfully executed on a "slave" database server.
Set Synchronous Replication to Async Mode
Important! Before changing the database replication mode, please read PostgreSQL documentation on Synchronous Replication.
- (Optional) Before you change the database replication mode, you may want to check the current replication mode. See Show Replication Mode.
- Go to the Scripts tab of the "master" database server and run the db_postgres::do_set_slave_async_mode operational script. Note: The script cannot be successfully executed on a "slave" database server.
- © Copyright 2015 RightScale Technical Support