Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Cluster Geographic Edition System Administration Guide Oracle Solaris Cluster 4.1 |
1. Introduction to Administering the Geographic Edition Software
3. Administering the Geographic Edition Infrastructure
4. Administering Access and Security
5. Administering Cluster Partnerships
7. Administering Protection Groups
8. Monitoring and Validating the Geographic Edition Software
9. Customizing Switchover and Takeover Actions
A. Standard Geographic Edition Properties
B. Legal Names and Values of Geographic Edition Entities
C. Disaster Recovery Administration Example
E. Troubleshooting Geographic Edition Software
F. Deployment Example: Replicating Data With MySQL
MySQL Replication Resource Group
MySQL Application Resource Group
Initial Configuration of MySQL Replication
Installing MySQL and Configuring the MySQL Database Resource Group
How to Configure the MySQL Replication
Configuring the MySQL Application Resource Group
Administering MySQL Protection Groups
Planning for Your MySQL Protection Group
Creating, Modifying, Validating, and Deleting a MySQL Protection Group
How to Create the MySQL Configuration
Modifying a MySQL Protection Group
Validating a MySQL Protection Group
How to Delete a MySQL Protection Group
Administering MySQL Application Resource Groups
How to Add an Application Resource Group to a MySQL Protection Group
How to Delete an Application Resource Group From a MySQL Protection Group
Administering MySQL Data-Replicated Components
How to Add a Data-Replicated Component to a MySQL Protection Group
Data Replication Subsystem Process for Verifying the Replicated Component
How to Modify a MySQL Data-Replicated Component
How to Delete a Data-Replicated Component From a MySQL Protection Group
Replicating a MySQL Protection Group Configuration to a Partner Cluster
Resynchronizing a MySQL Protection Group
Recovery Strategy After a Takeover of a MySQL Protection Group
How to Recover After a Takeover
This section describes the following tasks:
When you activate a protection group, it assumes the role that you assigned to it during configuration. For more information about configuring protection groups, see How to Create the MySQL Configuration.
You can activate a protection group in the following ways:
Globally, which activates a protection group on both clusters where the protection group has been configured
On the primary cluster only
On the secondary cluster only
Activate the protection group.
Use the following command to activate the protection group on the primary and secondary clusters depending on the scope of the command. When you activate a protection group on the primary cluster, its application resource groups are also brought online.
# geopg start -e scope [-n] MySQL-Protection-group
In this syntax, -e scope specifies the scope of the command. If the scope is local, the command operates on the local cluster only. If the scope is global, the command operates on both clusters that deploy the protection group.
Note - The property values, such as global and local, are not case sensitive.
Also in this syntax, -n prevents the start of data replication at protection group startup. If you omit this option, the geopg startcommand performs the following actions if the role of the protection group is secondary on the local cluster:
Starts the MySQL slave threads
Prevents modification by non-root roles if this option is configured
Prepares the my.cnf file to start the database with modifications prevented for non-root roles if this option is configured
Also in this syntax, MySQL-Protection-group specifies the name of the protection group.
The geopg startcommand uses the clresourcegroup online -M command to bring resource groups and resources online. For more information, see the clresourcegroup(1CL) man page.
The geopg startcommand performs the following actions if the role of the protection group is primary on the local cluster:
Prepares the my.cnf file to start the database without the slave threads
Brings online the application resource groups in the protection group on the local cluster
If the command fails, the configuration status might be set to Error depending on the cause of the failure. The protection group remains deactivated but data replication might be started, and some resource groups might be brought online. Run the geoadm statuscommand to obtain the status of your system.
If the configuration status is set to Error, revalidate the protection group by using the procedure described in Validating a MySQL Protection Group.
Example F-8 Globally Activating a MySQL Protection Group
In the following example, a protection group is globally activated:
# geopg start -e global mysql-pg
Example F-9 Locally Activating a MySQL Protection Group
In the following example, a protection group is activated on a local cluster only. This local cluster might be a primary cluster or a secondary cluster, depending on the role of the cluster.
# geopg start -e local mysql-pg
You can deactivate a protection group in the following ways:
Globally, meaning you deactivate a protection group on both the primary cluster and the secondary cluster where the protection group is configured
On the primary cluster only
On the secondary cluster only
Deactivate the protection group.
Use the following command to deactivate the protection group on all nodes of the primary and secondary clusters depending on the scope of the command. When you deactivate a protection group, its application resource groups are also unmanaged.
# geopg stop -e scope [-D] protection-group
In this syntax, -e scope specifies the scope of the command. If the scope is local, the command operates on the local cluster only. If the scope is global, the command operates on both clusters where the protection group is deployed.
Note - The property values, such as global and local, are not case-sensitive.
Also in this syntax, -D specifies that only data replication should be stopped and that the protection group should be online. If you omit this option, the data replication subsystem and the protection group are both stopped. If the role of the protection group on the local cluster is primary, omitting the -D option also results in taking the application resource groups offline and putting them in an unmanaged state.
In addition, protection-group specifies the name of the protection group.
If the geopg stopcommand fails, run the geoadm statuscommand to obtain the status of each component. For example, the configuration status might be set to Error depending on the cause of the failure. The protection group might remain activated even though some resource groups might be unmanaged. The protection group might be deactivated with data replication running.
If the configuration status is set to Error, revalidate the protection group by using the procedure described in Validating a MySQL Protection Group.
Example F-10 Deactivating a MySQL Protection Group on All Clusters
In the following example, a protection group is deactivated on all clusters:
# geopg stop -e global mysql-pg
Example F-11 Deactivating a MySQL Protection Group on a Local Cluster
In the following example, a protection group is deactivated on the local cluster:
# geopg stop -e local mysql-pg
Example F-12 Stopping MySQL Data Replication While Leaving the Protection Group Online
In the following example, data replication is stopped on the local cluster only:
# geopg stop -e local -D mysql-pg
If you decide later to deactivate both the protection group and its underlying data replication subsystem, you can rerun the command without the -D option. For example:
# geopg stop -e local mysql-pg
Example F-13 Deactivating a MySQL Protection Group While Keeping Application Resource Groups Online
In the following example, two application resource groups, apprg1 and apprg2, are kept online while their protection group, mysql-pg, is deactivated. First, the application resource groups are removed from the protection group. Then, the protection group is deactivated.
# geopg remove-resource-group apprg1,apprg2 mysql-pg # geopg stop -e global mysql-pg