Placing mount points associated with database-level mount resources into maintenance mode

You can perform maintenance on a specific mount point that is associated with a database level mount resource in the TSA resource model. Maintenance can be done without affecting the member resource's availability. This command must be run as the Db2® instance owner.

Before you begin

Important: To run the db2cm utility as the root user, ensure the DB2INSTANCE environment variable is set to the instance owner.

Prior to placing a mount point into maintenance mode, all activity that is accessing data on the mount point needs to be stopped. This involves deactivating the database on the associated hosts. For host-level maintenance mode, the database needs to be deactivated on the current host. For cluster-wide mount maintenance, the database needs to be deactivated on all member hosts.

At the application level, ensure that applications cannot access the database that resides on the mount point of the associated host that is being placed into maintenance mode.

The Usage scenarios section below provides examples of the steps that need to be performed.

About this task

There are two types of mount resources in the resource model:

Instance-level mount resource: maps to the instance shared directory (sqllib_shared).
Database-level mount resource: maps to the database container's mount points.

Note: Instance-level mount resources cannot be placed into maintenance mode, and these mount resources are defined on all hosts in the cluster. Database-level mount resources can be placed into maintenance mode, and these mount resources are only defined on the member hosts.

Restrictions

If a mount point is placed in host-level maintenance, it cannot be placed in cluster-wide level mount maintenance by using the -all option.
A mount point can be in single host mount maintenance as many times as the number of hosts that exist in the cluster at one time. (no quorum issue)
If multiple hosts have the same mount point in mount maintenance, the order of exiting mount maintenance from each host is irrelevant.
If a mount point is in host-level maintenance on all hosts, the user can exit mount maintenance on all hosts by using the -all option.
The user can exit host-level mount maintenance on a mount point as long as the mount is in maintenance mode on the current host (entered through host-level maintenance or cluster-wide maintenance).
Single host mount maintenance commands (enter and exit) must be executed on the same host.
All hosts mount maintenance commands (enter –all and exit –all) can be executed on any host.
Host-level mount maintenance operations cannot be issued on a caching facility CF-only host. Cluster-wide mount maintenance operations can be issued on any member or CF host in the cluster.

Preventing applications from connecting to a database on a specific member

In highly active environments, connections to the mount points may re-establish before the maintenance work is complete. There are two ways to prevent incoming connections to a database on a specific member:

Quiesce that member prior to entering maintenance on the mount point.
Use Member subsetting.

By quiescing the member first, the user can start the member after this operation completes.

To quiesce a specific member prior to entering maintenance on the mount point:

Quiesce the specific member by running the following command:
```
 db2stop MEMBER <member> QUIESCE <time_in_minutes>
```
Enter maintenance mode on the mount point.
Start the member by running the following command:
```
db2start member <member>
```
When the command executes, the member is shut down. The user cannot connect to any database through the member during this time.

To prevent incoming connections to a database on a specific member by using member subsetting:

Create a member subset for the database, consisting of all of the members in your Db2 data server environment. This allows applications to connect to the database, using the above database alias specified in the create member subset.
Drop the member from the member subset to prevent applications from connecting to a database through a specific member. For more information, see Adding or removing members from a member subset.

Note: Opting for the member subsetting workaround requires the user to update all of their client machines to use the new alias. This may be a time-consuming task depending on the number of client machines configured.

Examples

Example 1: A DBA determines that the specific mount point (/db2data) needs to be taken offline on a specific host. Entering mount maintenance (/db2data) on member 0 home host

Environment setup:

Two Members and one CF : M0, M1 and CF128.
Three shared file systems:
- /db2fs1 - Instance-level mount resource. sqllib_shared resides on this file system.
- /db2data - File system that holds database container files.
- /db2logs - File system that holds log files.

Action: The DBA plans to take '/db2data' offline on member M0 for maintenance activity.

Steps:

Force all applications off on member M0 using any databases that reside on /db2data. Applications that are actively connecting to the database through this member must be routed to other members.
Deactivate the database on /db2data from the member M0 home host:
```
db2 deactivate db <dbname> -member 0 -force
```
As instance owner on the member M0’s host, enter mount maintenance on /db2data:
```
db2cluster -enter -maintenance -mount /db2data
```
Verify that the mount point is in maintenance mode on the member M0 host:
```
db2cluster -verify -maintenance -mount /db2data
```
Perform the necessary maintenance work.
As instance owner on the member M0’s host, exit mount maintenance:
```
db2cluster -exit -maintenance -mount /db2data
```

Note: In highly active environments, connections may re-establish before the force operation completes. For information on how to prevent incoming connections to a database on a specific member, see Preventing applications from connecting to a database on a specific member above.

Example 2: A DBA determines a specific mount point (/data) to be taken offline on all hosts. Entering mount maintenance (/data) on all hosts

Environment setup:

Two Members and one CF : M0, M1 and CF128.
Three shared file systems:
- /db2fs1 - Instance-level mount resource. sqllib_shared resides on this file system.
- /data - File system that holds database container files.
- /logfiles - File system that holds log files.

Action: The DBA plans to take '/data' offline on all members for maintenance activity.

Steps:

Force all applications on all members using any DBs on /data.

Quiesce database that resides on /data:

db2 connect to <dbname>
db2 quiesce db immediate

Deactivate database on /data:
```
db2 deactivate db <dbname> -force
```
As instance owner on any host, enter mount maintenance on /data for all hosts:
```
  db2cluster -enter -maintenance -mount /data -all
```

Verify that mount is in maintenance mode on all host:

  db2cluster -verify -maintenance -mount /data -all

Perform the necessary maintenance work.
As instance owner on any host, exit mount maintenance from all hosts:
```
 db2cluster -exit -maintenance -mount /data -all
```

Unquiesce database on /data:

db2 connect to <dbname>
db2 unquiesce db