Protecting Symfoware Server/Enterprise Postgres

The following table explains the supported features when protecting Symfoware Server/Enterprise Postgres.

Support Range

• For Enterprise Postgres 14SP1 and Symfoware Server up to 12.4, only PostgreSQL-compatible features are supported.
• Enterprise Postgres version 15 and later support data encryption in addition to PostgreSQL-compatible features. (Other than encryption, PostgreSQL-incompatible features are not supported.)
• Database Mirroring functionality is not supported. If you want to create a mirror and have data redundancy, please use DataKeeper.
• The native interface of Symfoware Server is not supported. Use Open Interface (Symfoware 12.2), Postgres (Symfoware 12.3 or later).
• WebAdmin is asymmetry. For the details, refer to the Symfoware Server Cluster Operation Guide for Fujitsu Software.
• The following functions are not supported:
  • WAL duplication
  • Data concealing
  • Parallel search
  • In-memory

Configuration Notes

• Set up the environment variable, LD_LIBRARY_PATH is required to execute Symfoware commands (pg_ctl,psql, etc.) in the appropriate environment file (.bash_profile, etc.) for the DB Administration User (OS user) log-in.

Settings Required to use Transparent Data Encryption

As mentioned earlier, Enterprise Postgres version 15 or later supports the transparent data encryption feature provided by FUJITSU Software Enterprise Postgres. The PostgreSQL Recovery Kit must meet the following requirements:

• Do not use database multiplexing mode
• Tablespace directories are located on a drive (shared or mirrored disk) protected by volume resources
• Use the same master encryption key on both nodes
• Set auto-open on both nodes

The following settings are also recommended:
Place the keystore storage directory on the local drive (Ex.:/home/fsep/key/store/inst1) of the primary node and secondary node.

For settings related to the keystore storage directory, refer to the following example procedure to confirm the settings.

1. [On a primary node] Create a keystore storage folder and allow Database Administrator access
   

   $ mkdir -p /home/fsep/key/store/inst1
   

2. [On a primary node] Create a folder for a tablespace and allow Database Administrator access
   

   # mkdir -p /data/tablespace/inst1
   # chown fsep:fsep /data/tablespace/inst1
   # chmod 700 /data/tablespace/inst1
   

3. [On a primary node] Edit postgresql.conf and add the following lines
   

   keystore_location = '/home/fsep/key/store/inst1'
   

4. Take the PostgreSQL resource out of service and then bring it back in service
5. [On a primary node] Set the master encryption key
   

   $ psql -d template1
   > SELECT pgx_set_master_key('993bab1451d93055');
   

6. [On a primary node] Create a tablespace
   

   $ psql -d postgres	
   > CREATE TABLESPACE secure_tablespace LOCATION '/data/tablespace/inst1' WITH (tablespace_encryption_algorithm = 'AES256' );
   > SELECT spcname, spcencalgo FROM pg_tablespace ts, pgx_tablespaces tsx WHERE ts.oid = tsx.spctablespace;
   

7. [On a primary node] Create a table
   

   $ psql -d postgres
   > CREATE TABLE table02 (id integer,  name varchar(10)) TABLESPACE secure_tablespace;
   

8. [On a primary node] Set auto-open
   

   $ pgx_keystore --enable-auto-open /home/fsep/key/store/inst1/keystore.ks
   

9. Switchover a PostgreSQL resource hierarchy to the secondary node
10. [On a secondary node] Create a keystore storage folder and allow Database Administrator access
11. [On a secondary node] Create a folder for a tablespace and allow Database Administrator access
12. [On a secondary node] Copy the keystore file (/home/fsep/key/store/inst1/keystore.ks) ) from the primary node
13. [On a secondary node] Set auto-open
14. Switchover the PostgreSQL resource hierarchy to the primary node