JetPatch works with a PostgreSQL database. The recommended architecture for production environments is to run this database on a separate server, not on the JetPatch server.
Since deployments often start out with the PostgreSQL server running on the JetPatch server, migration to a new PostgreSQL server is a common task when going into production.
The following steps describe how to migrate the data from the JetPatch database from one server to another.
As a security best practice, it is highly recommended not to use a database superuser as the JetPatch user. Instead, log in as an a superuser, and create a new user and empty database:
CREATE USER <username> WITH CREATEDB PASSWORD '<password>';
CREATE DATABASE <dbname> WITH OWNER <username>;
If specifying the password as part of the user creation command, it is suggested to immediately change the password for the created user with a prompt-based utility. From the psql superuser prompt, this can be done with:
Database Migration Steps
- On the JetPatch server, stop the tomcat service to prevent it from writing to the database during the migration:
service tomcat stop
- Dump the database into a file. You can run this on any server that has the pg_dump utility:
pg_dump --host=<orighost> --port=<origport> --username=<origuser> --dbname=<origdbname> --format=p --no-owner --file=<db_dump_filename>
- Restore the database contents into the new database:
psql --host=<newhost> --port=<newport> --username=<newuser> --dbname=<newdbname> < <db_dump_filename>
- You can now test the restore by connecting to the new database and running a query. For example, you could use psql and check the users table:
echo 'SELECT username FROM appuser;' | psql --host=<newhost> --port=<newport> --username=<newuser>
- To make JetPatch use the new database, go back to the server configuration file at /usr/share/tomcat/default/conf/intigua.properties, and change the db.url property to reflect the new database settings:
- Restart the tomcat service with "service tomcat restart". Then wait a few minutes, and access the JetPatch user interface to verify it's working correctly.
- Once the migration has finished, you can proceed to delete the database dump file, and optionally also the old database.