Continuent Documentation

Search:
Page in Other Manuals

8.24. The tungsten_find_orphaned Command

Version Support: 5.4.1

The tungsten_find_orphaned command was added in versions 5.4.1 and 6.1.1

The tungsten_find_orphaned command assists with locating orphaned events in both the MySQL binary logs as well as in the THL.

This program is designed to handle three failure scenarios:

  1. Orphaned MySQL binary logs that were not extracted into THL before a failover

  2. Orphaned THL on old master that did not make it to the new master

  3. Orphaned slave THL on new master or online slave of the new master that did not get applied to the database before getting promoted to new master

The default action with no arguments is Scenario 1 to locate orphaned MySQL binary logs which have not been extracted into THL on an old master before recovery.

      For Scenarios 1 and 2

By default, the tungsten_find_orphaned command expects to be run on a (possibly failed) master before recovery.

Once any new slave THL is appended to any existing extracted THL, the tungsten_find_orphaned command will be unable to find the delta between the binlogs and the THL.

If any events are located in the binlogs that do not exist in the THL on disk, they will be counted, and a summary displayed at the end.

Instructions on how to display any actual orphaned events in the binary logs will be provided as well.

      For Scenario 2

If the latestEpochNumber from the new master `trepctl status` output is provided via the `-e {seqno}` option, tungsten_find_orphaned will check for THL differences from old to new masters.

      For Scenario 3

Use --new on a NEW master to attempt to automatically locate the latest trepsvc.log file and determine if there is orphaned THL which exists on disk but had not yet been applied to the database.

If tungsten_find_orphaned is unable to auto-locate the trepsvc.log file, please specify the full path to the latest one using --log (or -l).

Table 8.52. tungsten_find_orphaned Options

OptionDescription
--debug, -dEnable additional debug output.
--epoch, -eUse the --epoch option on an OLD master to specify the latestEpochNumber from the new master in order to find orphaned THL which did not get copied to the new master. Note: Use `tungsten_find_orphaned -E` on the new master to obtain the latestEpochNumber (Scenario 2)
--epochget, -EUse option --epochget on a NEW master to locate the latestEpochNumber for use on the OLD master with --epoch (sets quiet mode to true) (Scenario 2)
--help, -hShow help text
--log, -lUse option --log on a NEW master specify the full path to the latest trepsvc.log file. Used when tungsten_find_orphaned is unable to auto-locate trepsvc.log (Scenario 3)
--new, -nUse option --new on a NEW master to attempt to automatically locate the latest trepsvc.log file and determine if there is orphaned THL which exists on disk but had not yet been applied to the database. (Scenario 3)
--path, -pSpecify the full path to the executable directory where the thl and trepctl commands are located.
--quiet, -qPrevent final message from being output.
--service, -sSpecify the service name to use with the various commands.
--thlSpecify the full path to the thl command executable file.
--tpmSpecify the full path to the tpm command executable file.
--trepctlSpecify the full path to the trepctl command executable file.
--verbose, -vShow verbose output

Examples:

Run on old master to find orphaned binary logs not extracted to thl before failover with verbose output (Scenario 1):

shell> tungsten_find_orphaned -v

Locate THL on an old master that was not transferred to the new master before failover (Scenario 2):

shell> tungsten_find_orphaned -v -e {latestEpochNumber_from_new_master}

Run on new master to find unapplied THL (Scenario 3):

shell> tungsten_find_orphaned -v -n