Page History

...

1. User sees in the monitoring that the CMG majority is lost; they try to bring the lost nodes to life, this does not work
2. User issues a ‘cluster reset’ command passing new CMG nodes (these must be in the physical topology) (‘ignite recovery cluster reset –cmg–cluster-management-nodesgroup=<new-cmg-nodes>’)
3. The command gets sent to the first node from new-cmg-nodes
4. The node that got the repair command is the Repair Conductor
5. The general procedure for CMG recreation is invoked with new CMG nodes given in the command (see below)

...

1. User gets a notification about the absence of a majority of the MG
2. User tries to restart Ignite nodes hosting MG nodes (or just their RAFT nodes inside Ignite nodes)
3. If this does not work, the user issues a ‘cluster ‘recovery cluster reset {–cmg-nodes--cluster-management-group=<new-cmg-nodes>|--node=<existing-node>} --metastorage-replication-factor=N’ command first making sure that every possible node starts and joins. (If the user specifies the --node argument instead of --cluster-management-group, the command will take current CMG voting members set from the CMG leader (via --node); if the CMG is not available, the command will fail)
4. The general procedure for CMG recreation is invoked (see above); Metastorage-specific steps get executed after the CMG is recreated (see below)

...