In the following descriptions a term refers to any word or group of words that are language keywords, user-supplied values, literals, etc. A term’s exact meaning depends upon the context in which it is used.
Where x.x.x specifies the version information for the installer.If you are a Windows user, you can invoke the installer by right-clicking on the downloaded installer's icon, and selecting Run as Administrator.The setup wizard will automatically detect an existing agent, and upgrade the installed version (see Figure 2.3). Click Next to continue.When the Ready to Install dialog (shown in Figure 2.4) informs you that the installation is about to begin, click Next to continue.The PEM Agent Setup Wizard will inform you when the installation completes (see Figure 2.6). Click Finish to exit the wizard and close the window.
Where x.x.x specifies the version information for the installer.If you are a Windows user, you can invoke the installer by right-clicking on the downloaded installer's icon, and selecting Run as Administrator.The PEM Server Setup Wizard welcomes you, as shown in Figure 2.7. Click Next to continue to the License Agreement.The PEM server setup wizard will prompt you to accept the License Agreement (shown in Figure 2.8). After reviewing the license agreement, check the radio button next to I accept the agreement, and click Next to continue to the Existing installation dialog.The wizard then opens the Database Server Installation Details dialog, prompting you for connection credentials for database superuser of the PEM backing database (see Figure 2.11). Provide:
You must use an RPM to upgrade your PEM server on Linux host. For detailed information about using an RPM package to install PEM, please consult the PEM Installation Guide, available at:
If you are updating both PEM components and the PEM backing database, you should perform PEM component updates (the server, agents and client) before updating the backing database. For more information about updating PEM component software, see section 2.pg_upgrade supports a transfer of data between servers of the same type. For example, you can use pg_upgrade to move data from a PostgreSQL 9.6 backing database to a PostgreSQL 10 backing database, but not to an Advanced Server 10 backing database. If you wish to migrate to a different type of backing database (i.e from a PostgreSQL server to Advanced Server), please see Section 4 for details.You can optionally use a custom-built PostgreSQL server as a host of the PEM backing database. Note that if you are upgrading from a PostgreSQL backing database listening on port 5432, the new server must be configured to listen on a different port.The new backing database must be running the same version of sslutils that the current backing database is running; you can download the SSL Utils package that is used in EnterpriseDB installers at:You are not required to manually add the sslutils extension when using the Advanced Server as the new backing database. The process of configuring sslutils is platform-specific.When the download completes, extract the sslutils folder, and move it into the Postgres installation directory for the Postgres version to which you are upgrading.Open a command line, assume superuser privileges, and set the value of the PATH environment variable to allow make to locate the pg_config program:Postgres specifies either:
SET GETTEXTPATH=path_to_gettext
SET OPENSSLPATH=path_to_openssl
SET PGPATH=path_to_pg_installation_dir
SET ARCH=x86
msbuild sslutils.proj /p:Configuration=Releasepath_to_gettext specifies the location of the GETTEXT library and header files.path_to_openssl specifies the location of the openssl library and header files.path_to_pg_installation_dir specifies the location of the Postgres installation.SET USE_PGXS=1
SET OPENSSLPATH=C:\OpenSSL-Win32
SET GETTEXTPATH="C:\Program Files\PostgreSQL\10"
SET PGPATH="C:\Program Files\PostgreSQL\10"
SET ARCH=x86
msbuild sslutils.proj /p:Configuration=ReleaseCopy the compiled sslutils files to the appropriate directory for your installation; for example:Where service_name specifies the name of the Postgres service.On Windows, you can use the Services dialog to control the service. To open the Services dialog, navigate through the Control Panel to the System and Security menu. Select Administrative Tools, and then double-click the Services icon. When the Services dialog opens, highlight the service name in the list, and use the option provided on the dialog to Stop the service.You can use the pg_upgrade utility to perform an in-place transfer of existing data between the old backing database and the new backing database. If your server is configured to enforce md5 authentication, you may need to add an entry to the .pgpass file that specifies the connection properties (and password) for the database superuser, or modify the pg_hba.conf file to allow trust connections before invoking pg_upgrade. For more information about creating an entry in the .pgpass file, please see the PostgreSQL core documentation, available at:During the upgrade process, pg_upgrade will write a series of log files. The cluster owner must invoke pg_upgrade from a directory in which they have write privileges. If the upgrade completes successfully, pg_upgrade will remove the log files when the upgrade completes. To instruct pg_upgrade to not delete the upgrade log files, include the --retain keyword when invoking pg_upgrade.path_to_pg_upgrade/pg_upgrade
-d old_data_dir_path
-D new_data_dir_path
-b old_bin_dir_path -B new_bin_dir_path
-p old_port -P new_port
-u user_namepath_to_pg_upgrade specifies the location of the pg_upgrade utility. By default, pg_upgrade is installed in the bin directory under your Postgres directory.old_data_dir_path specifies the complete path to the data directory of the old backing database.new_data_dir_path specifies the complete path to the data directory of the new backing database.old_bin_dir_path specifies the complete path to the bin directory of the old backing database.new_bin_dir_path specifies the complete path to the bin directory of the old backing database.old_port specifies the port on which the old server is listening.user_name specifies the name of the cluster owner.Copy the following certificate files from the data directory of the old backing database to the data directory of the new backing database:
The backing database of the target server may be a different version or type than the backing database of the source. If the new PEM server does not reside on the same type of backing database as the original server, you must ensure that the same version of the sslutils extension is installed on the new server host. The version of sslutils that is distributed with the PEM installers is freely available for download from the EnterpriseDB website at:For information about installing the PEM server or the sslutils extension, please refer to the PEM Installation Guide, available at:The migration process re-creates the pem, pemdata, and pemhistory schemas from the source PEM server on the target PEM server. In preparation for the move, use the psql client to delete these schemas from the pem database on the target host. You can open the psql client at the command line, or by selecting SQL Shell (psql) from the Postgres Enterprise Manager menu.When the psql client opens, connect to the pem backing database as the database superuser. After connecting to the pem database on the target host, use the following commands to drop the schemas:When dropping the schemas, you must include the CASCADE keyword, instructing the server to delete all dependent objects. When executing the command, the psql client displays a list of the dependent objects; the client confirms each the schema is removed by displaying DROP SCHEMA (as shown in Figure 4.1).Before moving the PEM server, you must identify the number of agents that are monitored by the source PEM server, and create identities for that number of agents (less one) on the target server. To discover the total number of PEM agents monitored by the PEM server, connect to the pem database on the source host with the psql client, and query the pem.agent table (as shown in Figure 4.2).SELECT id FROM pem.agent WHERE active = true;You must manually create the number of agents that reside on the original PEM server, less one; the PEM server installer has already created one agent on the target host. For example, if the source server contains three agents, you must manually create two additional agents. Open a psql session with the pem database on the target server, and create the required agents. Use the command:Where x specifies an agent number (see Figure 4.3). Remember, agent1 is created on the target host by the PEM server installer.Then, use the GRANT command to assign each agent that resides on the target PEM server pem_agent permissions:Where x specifies an agent number (see Figure 4.4).You can use the pg_dump utility to generate a script that contains the commands required to recreate the pem database on the target host. By default, pg_dump is installed in the bin directory under your Postgres installation. To invoke pg_dump, open a command line, navigate to the bin directory, and enter:user_name specifies the name of the database superuser for the PEM backing database.file_name specifies the name of the script generated by pg_dump.The command shown in Figure 4.5 instructs pg_dump to generate a script that (when executed) will re-create the pem database. The script will be named backup.sql, and will be created in the tmp directory. pg_dump is connecting to the server using the credentials of the user, postgres.Note that invoking the pg_dump utility will not interrupt current database users.Move the script generated by the pg_dump utility to the target host of the PEM server.Open a command line on the target host and navigate into the bin directory (under the Postgres backing database installation directory). Start psql, executing the script generated by the pg_dump utility:user_name specifies the name of the database superuser. The user specified must have connection privileges for the backing database.The example shown in Figure 4.6 uses the psql client to invoke a script named backup.sql to recreate the pem database. The script is invoked using the privileges associated with the database superuser, postgres.service_name specifies the name of the backing database server. For a PostgreSQL backing database, the service name is postgresql-x.x, and for an Advanced Server backing database, the service name is ppas-x.x, where x specifies the version number.If you are using Windows, you can use the Services dialog to control the service. To open the Services dialog, navigate through the Control Panel to the System and Security menu. Select Administrative Tools, and then double-click the Services icon. When the Services dialog opens, highlight the service name in the list, and use the option provided on the dialog to Stop the service.Copy the files to the data directory under the Postgres installation that provides the backing database for the target cluster. On Linux, by default, the files reside in:
The default installation location for the PEM server when installed by the graphical installer is /opt/edb/pem. In the example that follows, substitute your server installation location for PEM_installation_path.
The default installation location for the PEM server when installed by the graphical installer is /opt/edb/pem. In the example that follows, substitute your server installation location for PEM_installation_path.
When restoring the pem backing database from backup, you may encounter an error during the restoration of the pem.alert table. This is caused by a missing table pre-requisite for the table - the pg_restore utility may restore the pem.alert pre-requisites after it attempts to restore pem.alert.If this happens, the output from pg_restore will include error messages that refer to the alert table:If you encounter this problem, restore the pem database before restoring the pem.alert table. Restoring the pem database will install the pre-requisites for pem.alert, and the restoration of the table should complete as expected.