7.3
Table Of Contents
- Managing vRealize Automation
- Contents
- Managing vRealize Automation
- Updated Information
- Maintaining and Customizing vRealize Automation Components and Options
- Broadcast a Message on the Message Board Portlet
- Starting Up and Shutting Down vRealize Automation
- Updating vRealize Automation Certificates
- Extracting Certificates and Private Keys
- Replace Certificates in the vRealize Automation Appliance
- Replace the Infrastructure as a Service Certificate
- Replace the IaaS Manager Service Certificate
- Update Embedded vRealize Orchestrator to Trust vRealize Automation Certificates
- Update External vRealize Orchestrator to Trust vRealize Automation Certificates
- Updating the vRealize Automation Appliance Management Site Certificate
- Replace a Management Agent Certificate
- Change the Polling Method for Certificates
- Managing the vRealize Automation Postgres Appliance Database
- Backup and Recovery for vRealize Automation Installations
- The Customer Experience Improvement Program
- Adjusting System Settings
- Monitoring vRealize Automation
- Monitoring vRealize Automation Health
- Monitoring and Managing Resources
- Monitoring Containers
- Bulk Import, Update, or Migrate Virtual Machines
Procedure
1 Try to recover the database using the Virtual Appliance Management Interface from one of the
database nodes.
a If possible, open the Virtual Appliance Management Interface database page of the node with the
most recent state. Typically, this node is the one that was the master node before the database
failed.
b If the Virtual Appliance Management Interface for the master node fails to open, try to open the
Interface for other replica nodes.
c If you can find a database node with a working Virtual Appliance Management Interface, try to
recover it by performing a manual failover.
See Scenario: Perform Manual vRealize Automation Appliance Database Failover.
2 If the procedure in step 1 fails, start a shell session and try to determine the node with the most
recent state. Start a shell session to all the available cluster nodes and try to start their databases by
running the following shell command: service vpostgres start
3 Use the following procedure for each node that has a running local database to determine the node
with the most recent state.
a Run the following command to determine the node with the most recent state. If the command
returns f, then it is the node with most recent state and you can proceed to step 4.
su - postgres
psql vcac
vcac=# select pg_is_in_recovery();
pg_is_in_recovery
n
If this command returns an f, then this node has the most recent state.
n
If the node returns a t, run the following command on the node:
SELECT pg_last_xlog_receive_location() as receive_loc, pg_last_xlog_replay_location() as
replay_loc, extract(epoch from pg_last_xact_replay_timestamp()) as replay_timestamp;
This command should return a result similar to the following.
vcac=# SELECT pg_last_xlog_receive_location() as receive_loc, pg_last_xlog_replay_location()
as replay_loc, extract(epoch from pg_last_xact_replay_timestamp()) as replay_timestamp;
receive_loc | replay_loc | replay_timestamp
-------------+------------+------------------
0/20000000 | 0/203228A0 | 1491577215.68858
(1 row)
4 Compare the results for each node to determine which one has the most recent state.
Select the node with greatest value under the receive_loc column. If equal, select the greatest from
the replay_loc column and then, if again equal, select the node with greatest value of
replay_timestamp.
Managing vRealize Automation
VMware, Inc. 38