Replacing an existing Tivoli SA MP-managed Db2 instance with a Pacemaker-managed Mutual Failover Db2 instance

If you are running Db2 on a Linux cluster that is managed by IBM Tivoli System Automation for Multiplatforms (SA MP), you can use the db2cm utility to replace cluster management with Pacemaker, and enable the Mutual Failover high availability option.

About this task

Important: In Db2® 11.5.8 and later, Mutual Failover high availability is supported when using Pacemaker as the integrated cluster manager. In Db2 11.5.6 and later, the Pacemaker cluster manager for automated fail-over to HADR standby databases is packaged and installed with Db2. In Db2 11.5.5, Pacemaker is included and available for production environments. In Db2 11.5.4, Pacemaker is included as a technology preview only, for development, test, and proof-of-concept environments.
Take note of the following information before you start your conversion:
  • Db2 clients can be disconnected during this operation if the original cluster is configured to use a virtual IP address (VIP).
  • The Db2 Mutual Failover hosts remain online throughout the operation but the automated failover to the Mutual Failover standby is disabled during the conversion. No takeover is required..
  • When running db2cm, ensure that you run the command as the root user.
The following placeholders are used in the command statements throughout this procedure:
  • <exportedFile> is the name of the file to which the instance owner backs up their existing SA MP cluster configuration.
  • <hostname1> and <hostname2> are the host names for the primary and standby network interfaces in the cluster.
  • <network_interface_name> is the name of the device on the cluster.
  • <partition_number> is a unique number that identifies the database partition server in the Db2 Pacemaker cluster. For more information, see dbpartitionnum.
  • <database_name> is the name of the Db2 database.
  • <instance_name> is the name of the Db2 instance on the cluster
  • <domain_name> is the domain name of the cluster.
Note: The following procedure assumes an in-version conversion, which means that there is no change in the Db2 version.

Procedure

  1. As an instance owner, back up the existing Tivoli SA MP cluster configuration by exporting it to an xml file using the following command:
    db2haicu -o <exportedFile>.xml
  2. As an instance owner, delete the Tivoli SA MP resource model on both the primary and standby hosts using the following command:
    db2haicu -delete
  3. Run db2cm to create the cluster for your Mutual Failover Pacemaker configuration.
    INSTANCE_HOME/sqllib/bin/db2cm -create -cluster -domain <domain_name>    
        -host <hostname1> -publicEthernet <network_interface_name> 
        -host <hostname2> -publicEthernet <network_interface_name>
  4. Run db2cm to create the partition resources for the Mutual Failover cluster.
    INSTANCE_HOME/sqllib/bin/db2cm -create –partition <partition_number> -instance <instance_name>
  5. Optional: Run db2cm to add the database mounts.
    INSTANCE_HOME/sqllib/bin/db2cm -add -dbMount <database_name> -partition <partition_number> -instance <instance_name>
  6. Run db2cm to create the primary VIP resource for the specified partition.
    INSTANCE_HOME/sqllib/bin/db2cm -create -primaryVIP<IPv4 Address> –partition <partition number> -instance <instance name>
  7. Validate that the resource model contains a partition resource, a VIP resource, and a mount resource:
    INSTANCE_HOME/sqllib/bin/db2cm -list

Examples

The following example shows the db2cm command syntax for creating a Mutual Failover cluster (see step 3).
 INSTANCE_HOME/sqllib/bin/db2cm -create -cluster -domain hadom    
    -host ip-172-31-15-79 -publicEthernet eth1 
    -host ip-172-31-10-145 -publicEthernet eth1
The following example shows the output from running the db2cm -list command to validate the existence of a partition resource, a VIP resource, and a mount resource in the resource model (see step 7):
Cluster Status
Domain information:
Domain name               = hadom
Pacemaker version         = 2.1.2-4.db2pcmk.el8
Corosync version          = 3.1.6
Current domain leader     = hadom-srv-1
Number of nodes           = 2
Number of resources       = 6
Node information:
Name name           State
---------------    -------
hadom-srv-1          Online
hadom-srv-2          Online

Resource Information:
Resource Name          = db2_regress1_0
  State                   = Online
  Managed                 = true
  Resource Type           = Partition
  Instance                = regress1
  Partition               = 0
  Current Host            = hadom-srv-1

Resource Name          = db2_regress1_0-VIP
  State                   = Online
  Managed                 = true
  Resource Type           = IP
    Node                  = hadom-srv-1
    Ip Address            = 10.31.40.10
  Location                = hadom-srv-1

Resource Name          = db2_regress1_0-instmnt_db2hamf
  State                   = Online
  Managed                 = true
  Resource Type           = File System
  Device                  = "/dev/sdb"
  Mount Point             = "/db2hamf"
  File System Type        = ext3  
  Mount Options           = "rw,relatime"
  Current Host            = hadom-srv-1

Resource Name          = db2_regress1_0-mnt_db2hamf2
  State                   = Online
  Managed                 = true
  Resource Type           = File System
  Device                  = "/dev/sda"
  Mount Point             = "/db2hamf2"  
  File System Type        = ext3
  Mount Options           = "acl,user_xattr,noauto"
  Current Host            = hadom-srv-1

Resource Name          = db2_hadom-srv-1_eth0
  State                   = Online
  Managed                 = true
  Resource Type           = Network Interface
  Node                    = hadom-srv-1
  Interface Name          = eth0
  
Resource Name          = db2_hadom-srv-2_eth0
  State                   = Online
  Managed                 = true
  Resource Type           = Network Interface
    Node                  = hadom-srv-2
    Interface Name        = eth0

Fencing Information:
  Configured
Quorum Information:
  Qdevice

Qdevice information
-------------------
Model:                 Net
Node ID:               1
Configured node list:
0   Node ID = 1
1   Node ID = 2
Membership node list:   1, 2

Qdevice-net information
----------------------
Cluster name:           hadom
QNetd host:             hadom-disk:5403
Algorithm:              LMS
Tie-breaker:            Node with lowestnode ID
State:                  Connected