Preinstalled Server images, such as Amazon Machine Images (AMIs) and OVA files, include a local PostgreSQL database.
For a production installation, it is recommended to replace the use of this database with an external PostgreSQL server. The external server can be a separate virtual machine, or a managed database service such as Amazon RDS.
The best time to change the database used by the JetPatch server is immediately after launching it. In this case, there is no need to migrate any data. In case the migration is done at a later time, you should also port the data as part of migration process. See Migrating the Database.
To use the new database, JetPatch Agent Manager will need the following:
JetPatch Agent Manager is not a particularly heavy application in terms of database load. In RDS, it's recommended to start out with a low number of provisioned IOPS, and scale it later if needed.
Changing the Database in Use
- Log into the JetPatch server.
- Stop tomcat by running: sudo service tomcat stop
- Configure the database connection, by editing the file
- Turn off, disable and remove the preinstalled postgreSQL server, and restart Tomcat:
sudo systemctl stop postgresql-9.5
sudo systemctl disable postgresql-9.5
sudo yum remove -y postgresql95-server
sudo systemctl start tomcat
Testing the change
A few minutes after starting Tomcat, log into the JetPatch server. Note that the first startup after a database change takes a bit more time than usual, due to the database initialization.
In case there are issues, check the log files at /usr/share/tomcat/default/logs/ for diagnostic information.
In case of a database failover to a secondary site or availability zone,JetPatch Agent Manager console and API operations may fail or hang due to presence on the JetPatch server of pooled database connections which are still pointing towards the failed database instance. Therefore it is recommended to follow any database failover with a restart of the JetPatch server, which will refresh the entire database connection pool.