Shutting down the Postgres database

Shut down the Postgres database to ensure no changes are made to the database during migration.

Instructions:

Shutting down Postgres database in Management subsystem on Kubernetes or VMware

When using s3 backup configuration for the Management subsystem, the following steps should be run on the source system, before the target API Connect system is installed.

  1. If on a VMware appliance deployment, connect to the Management node and log in as root user (sudo -i), so that you can run kubectl.
  2. Enable pgo client:
    kubectl set env deploy/ibm-apiconnect ENABLE_PGO_CLIENT="true" -n OPERATOR_NAMESPACE
  3. Wait for pgo-client pod to come up.
  4. Bring down the apic operator:
    kubectl scale deploy ibm-apiconnect --replicas=0 -n OPERATOR_NAMESPACE
  5. Scale down deployments.
    Before scaling down the deployments, make a note of the current replicas:
    kubectl get deployment -n namespace
    • Standard deployments :
      • juhu
      • portal-proxy
      • apim
      • lur
      • taskmanager
      • hub (when Test and Monitor is enabled)
    1. Scale down:
      kubectl scale deploy <deployment_name> --replicas=0 -n NAMESPACE
    2. To get the name of the Postgres cluster:
      kubectl get pgcluster -n NAMESPACE
    3. Connect to pgo client pod and run:
      pgo update cluster PG_CLUSTER_NAME --shutdown -n NAMEPSACE

Shutting down Postgres database in Management subsystem on OpenShift

When using s3 configuration, the following steps should be run on the source system, before the target API Connect system is installed.

  1. Change to operator namespace: 
    oc project "{OPERATOR NS}"
  2. oc edit csv ibm-apiconnect.v2.4.0
    1. Search for APPLIANCE and add these two lines above it: 
      - name: ENABLE_PGO_CLIENT
  value: "true"
    2. Save and wait for the pgo-client pod to come up.
  3. oc scale deploy ibm-apiconnect --replicas=0
  4. Bring down apiconnect operator pod: 
    oc scale deploy ibm-apiconnect --replicas=0
  5. Change to the namespace where API Connect is installed: 
    oc project "{APIC NS}"
  6. Scale down the following deployments: juhu, portal-proxy, apim, lur, taskmanager 
    oc scale deploy JUHU_DEPLOYMENT_NAME --replicas=0
oc scale deploy PORTAL_PROXY_DEPLOYMENT_NAME --replicas=0
oc scale deploy APIM_DEPLOYMENT_NAME --replicas=0
oc scale deploy LUR_DEPLOYMENT_NAME --replicas=0
oc scale deploy TASKMANAGER_DEPLOYMENT_NAME --replicas=0
  7. To get the name of the pg cluster: 
    oc get pgcluster
  8. Log in to pgo client pod: 
    oc exec -it $(oc get po|grep pgo|awk '{print $1}') -- bash
  9. Shutdown Postgres database:
    pgo update cluster PG_CLUSTER_NAME --shutdown -n NAMESPACE

Starting the Postgres database in the Management subsystem on Kubernetes and OVA

Use these steps when you are moving back to the source system because the migration failed, and you want to bring up the Postgres database, if it was shutdown.

  1. If on an appliance (VMware), connect to the Management node and log in as root user (sudo -i), so that you can run the kubectl commands.
  2. Get the name of the Postgres cluster:
    kubectl get pgcluster -n NAMESPACE
  3. Connect to the pgo client pod and run the command:
    pgo update cluster PG_CLUSTER_NAME --startup -n NAMESPACE
  4. Scale up the deployments that use Postgres.

    Standard deployments : juhu, portal-proxy, apim, lur, taskmanager, hub (when test and monitor is enabled)

    kubectl scale deploy DEPLOYMENT_NAME --replicas=N -n NAMEPSACE

    The value of N is from the kubectl get deployment -n namespace output that you got before shutting down the Postgres database. It is 1 if using n1 profile, and 3 when using n3 profile.

  5. Bring up the apic operator:
    kubectl scale deploy ibm-apiconnect --replicas=1 -n OPERATOR_NAMESPACE
  6. If s3 backups are used, perform a Management restore with the backup that was taken as part of Preparing the source system.
    Note: Any backups that are taken on the target system are not valid for the source system. The backups must not be used during restoration.
  7. Ensure that all subsystems are healthy.

Starting postgres database on the Management subsystem on OpenShift

Use these steps when you are moving back to the source system because the migration failed, and you want to bring up the Postgres database, if it was shutdown.

  1. Change to the project where the top-level CR (apic) is installed:
    oc project APIC_NAMESPACE
  2. Get the name of the Postgres cluster:
    oc get pgcluster
  3. Log in to pgo client pod:
    oc exec -it $(oc get po|grep pgo|awk '{print $1}') -- bash
  4. Start the postgres database:
    pgo update cluster PG_CLUSTER_NAME --startup -n NAMESPACE
  5. Scale up the deployments: juhu, portal-proxy, apim, lur, and taskmanager. Use the following commands, where N is the value of replicas. If an n1 profile being used the value is 1, and if an n3 profile is being used the value is 3.
    • oc scale deploy JUHU_DEPLOYMENT_NAME --replicas=N
    • oc scale deploy PORTAL_PROXY_DEPLOYMENT_NAME --replicas=N
    • oc scale deploy APIM_DEPLOYMENT_NAME --replicas=N
    • oc scale deploy LUR_DEPLOYMENT_NAME --replicas=N
    • oc scale deploy TASKMANAGER_DEPLOYMENT_NAME --replicas=N
  6. Bring down the apiconnect operator pod:
    oc scale deploy ibm-apiconnect --replicas=1 -n OPERATOR_NAMESPACE
  7. If s3 backups are used, perform a Management restore with the backup that was taken as part of Preparing the source system.
    Note: Any backups that are taken on the target system are not valid for the source system. The backups must not be used during restoration.
  8. Ensure that all subsystems are healthy.