Administering MySQL Protection Groups

A MySQL protection group must cover at least one MySQL database per cluster. It cannot protect anything other than MySQL databases. So, if your partnership contains additional replication protocols, you must create separate protection groups for them.

Planning for Your MySQL Protection Group

A MySQL database resource group can belong to only one protection group.

The MySQL geographic replication was developed with the script-based plug-in module of Geographic Edition, so it must comply with all rules of the script-based plug-in. For each protection group, you must provide a script-based plug-in configuration file on each node. In addition, the MySQL geographic replication brings in its own configuration file, which is needed only at registration.

The MySQL geographic replication creation is an automated process that takes the MySQL geographic configuration file as input and performs the necessary actions. The essential content of this file consists of key=value pairs.

Key	Explanation of Value
`PS`	Name of the partnership.
`PG`	Name of the protection group to create.
`REPCOMP`	Name of the replicated component to create in this protection group.
`REPRS`	Name of the replication resource.
`REPRG`	Name of the replication resource group.
`DESC`	Description for the protection group.
`CONFIGFILE`	Absolute path for the script-based plug-in configuration file.
`REALMYSRG`	Resource group names that contain the MySQL database resource on the clusters. If the resource group names on the clusters differ, provide a comma-separated list.
`REALMYSRS`	Resource names configured as the master and slave MySQL database resources. If the resource names on the clusters differ, provide a comma-separated list.
`READONLY`	Switch for setting the read-only variable on the MySQL slave. If the read-only variable should not be set, leave this value undefined. Any entry here triggers the read-only variable to be set.
`AAPRG`	Application resource group, which is unmanaged and contains at least the logical host for client access.
`LONGPING`	Timeout for the extensive `ping` test. The default is 60 seconds if this variable is unset. This timeout is used at `check_takeover` where it must be verified as the remote site is unavailable.
`SHORTPING`	Timeout for the short `ping` test. The default is 10 seconds if this variable is unset. The short `ping` timeout is used whenever a connection should succeed but is not required to succeed.

Skip Navigation Links
Exit Print View
	Oracle Solaris Cluster Geographic Edition System Administration Guide Oracle Solaris Cluster 4.1