1Z0-908 · Question #35
An attempt to recover an InnoDB Cluster fails. Examine this set of messages and responses: host3:3377 ssl JS > dba.rebootClusterFromCompleteOutage() Reconfiguring the default cluster from complete…
The correct answer is C. The instance deployed on host3 must be synchronized from a donor deployed on host1 by using. Option C is correct because the error explicitly tells you that host3 is lagging behind host1 in terms of applied transactions (GTIDs). Since host3 is not the most up-to-date, it cannot be used as the seed for the reboot - host3 must first be brought in sync by using host1 as a…
Question
An attempt to recover an InnoDB Cluster fails. Examine this set of messages and responses:
host3:3377 ssl JS > dba.rebootClusterFromCompleteOutage() Reconfiguring the default cluster from complete outage... The instance host1:3377'' was part of the cluster configuration. Would you like to rejoin it to the cluster? [y/N]: y The instance host2:3377' was part of the cluster configuration. Would you like to rejoin it to the cluster? [y/N]: y Dba.rebootClusterFromCompleteOutage: The active session instance isn't the most updated in comparison with the ONLINE instances of the Cluster's metadata. Please use the most up to date instance: `host1:3377'. (RuntimeError) Which statement is true?
Options
- AThe instance deployed on host3 must be rebuilt with a backup from the primary instance.
- BThe cluster is running and there is at least one ONLINE instance.
- CThe instance deployed on host3 must be synchronized from a donor deployed on host1 by using
- DIt is possible to determine the most up-to-date instance by comparing different global transaction
- EThe active session instance is invalid and must be re-created by using the command shell.connect
How the community answered
(29 responses)- A10% (3)
- B3% (1)
- C66% (19)
- D3% (1)
- E17% (5)
Explanation
Option C is correct because the error explicitly tells you that host3 is lagging behind host1 in terms of applied transactions (GTIDs). Since host3 is not the most up-to-date, it cannot be used as the seed for the reboot - host3 must first be brought in sync by using host1 as a donor (via MySQL Clone or equivalent), or the administrator must reconnect to host1 and run rebootClusterFromCompleteOutage() from there.
Why the others are wrong:
- A is too drastic - a full rebuild from backup is unnecessary; incremental synchronization from a donor is sufficient.
- B is false -
rebootClusterFromCompleteOutage()is only used when all instances are offline; the "ONLINE" in the error refers to metadata state, not live cluster status. - D is misleading - while GTID sets are indeed how MySQL identifies the most up-to-date instance internally, the system has already done this comparison and told you the answer (
host1); no manual comparison is needed. - E is incorrect - the session is not invalid or broken; the fix is simply connecting to
host1:3377and rerunning the command, not re-creating anything.
Memory tip: Think of rebootClusterFromCompleteOutage() as an election - the instance with the most votes (highest GTID) must be the one to call the meeting. If you try to run it from a laggard node, MySQL sends you back to find the real leader.
Topics
Community Discussion
No community discussion yet for this question.