Metasets and mediators
By Jean-Christophe Lamoure on Mar 25, 2009
When you have a 2 node configuration, with exactly 2 shared storage, a failure of one storage can alter the availability of the whole configuration.
To Alleviate this , the mediator have been introduced. ( added via the metaset -s xxx -a -m )
Mediator are held in memory, on the nodes, and act as a supplemental replica.
Mediator have 2 states : normal and golden. By default mediator hosts are in “normal” state
When should mediator hosts be in a Golden state? To avoid unnecessary user intervention in a dual-string failure situation, the concept of a golden mediator has been implemented. If exactly half of the metastate database replicas are accessible; and an event occurs that causes the mediator hosts to be updated; then two mediator updates are attempted. The first update attempts to change the commit count and to set the mediator to `NOT GOLDEN'. Then second update occurs if, and ONLY if, during the first phase all of the mediator hosts were successfully contacted, AND the number of replicas that were accessible and had their commit count advanced, AND this number of replicas is exactly half of the total number of replicas. If all of these conditions are met, the second update sets the mediator status to GOLDEN. This Golden Status enables a takeover to occur on the host with the Golden Status (without any user intervention). If the status is not Golden, then the data (Diskset devices and corresponding filesystems) will be set to Read-Only mode, and user intervention is required for a diskset takeover or failover to succeed; that is, if exactly half of the replicas are accessible. If less than th majority of the set replicas are accessible, then the following user intervention is required: o force the takeover of the particular diskset(s) o repair the affected diskset(s) metadevices and replicas o release the particular diskset(s) o retake the particular diskset(s) The golden state is stored in volatile memory (RAM) only. Once a takeover occurs, the mediator data is once again updated. If any mediator hosts cannot be updated, the golden state is revoked. Since the state is in RAM only, a reboot of a mediator host causes the golden state to be revoked. [c-220ra-2-epar03][root(43)] medstat -s nfs_dg Mediator Status Golden c-220ra-1-epar03 Ok No c-220ra-2-epar03 Ok No
difference between :
metaset -s xxx -t and metaset -s xxx -C take :
the first one interacts with the clsuter framework, while the second doesn't.
So If you have to import the set to fix some import issue, you'll probably have to use metaset -s xxx -C take, then metaset -s xxx -C release.
(maybe with the -f option ( force) for the import ) .
difference between :
metaset -s xxx -C purge and metaset -s xxx -P :
the first one does not interact with the cluster ( and the ccr) while the second also update the ccr on the node where it's run.
If the first one have been run, then later if you attempt to create a set with the same name, you may get the message “no such set”
so depending of what you want to do ( and what does not returns errors ! ) use one or the other.
If the set is still in the ccr, but not in the metadb configuration, you can use the following command to remove the entry form ccr :
/usr/cluster/dtk/bin/dcs_config -c remove -s <metaset name> (you'll need to install the dtk to get this command).
Solution 204877 : Sun[TM] Cluster 3.x: Troubleshooting loss of Solaris[TM] Volume manager metadb quorum