Explanation for TIBCO LogLogic LMI message "SQL peer exec: cluster is not enabled" when executing rebuild_stdatafiles
Article ID: KB0077904
Updated On:
| Products | Versions |
|---|---|
| TIBCO LogLogic Enterprise Virtual Appliance | 6.1.0 and higher |
Description
Starting in LMI 6.1.0, in the output from the rebuild_stdatafiles command you will see output similar to this:
querying for non-dedicated entriesTotal: 77:30:25 ETA: 77:23:46
for retention, using 365(raw data), 30(indexer) for file /loglogic/data/vol1/2018/02/14/1800/rawdata_10049_1518634080_60-365.txt.gz
adding /loglogic/data/vol1/2018/02/14/1800/rawdata_10049_1518634080_60-365.txt.gz, retention 365 days/index 30 days, start time 1518634080, timespan 60
SQL peer exec: cluster is not enabled
If you are executing the command on a standalone appliance (i.e. High Availability is disabled) then you will see the "SQL peer exec" message that is logged for every processed file. This message is not an error or even a warning. Although no log level is specified for it it is just an informational message to inform you that High Availability (HA) is disabled.
The reason rebuild_stdatafiles performs this check is because just prior to inserting the record into the stDataFiles table the rebuild command will issue a delete query on the standby appliance to delete any entry in stDataFiles that matches the filename being processed. This ensures that the information the standby contains in stDataFiles for a given file matches what the master appliance contains. After the record is inserted into the master appliance's stDataFiles the MySQL database replication feature will ensure the standby appliance receives the new record and there won't be any chance of it conflicting with any existing record because those will have already been deleted by the rebuild command.
In a future LMI version, this message will be suppressed by being moved to debug-level logging.
querying for non-dedicated entriesTotal: 77:30:25 ETA: 77:23:46
for retention, using 365(raw data), 30(indexer) for file /loglogic/data/vol1/2018/02/14/1800/rawdata_10049_1518634080_60-365.txt.gz
adding /loglogic/data/vol1/2018/02/14/1800/rawdata_10049_1518634080_60-365.txt.gz, retention 365 days/index 30 days, start time 1518634080, timespan 60
SQL peer exec: cluster is not enabled
If you are executing the command on a standalone appliance (i.e. High Availability is disabled) then you will see the "SQL peer exec" message that is logged for every processed file. This message is not an error or even a warning. Although no log level is specified for it it is just an informational message to inform you that High Availability (HA) is disabled.
The reason rebuild_stdatafiles performs this check is because just prior to inserting the record into the stDataFiles table the rebuild command will issue a delete query on the standby appliance to delete any entry in stDataFiles that matches the filename being processed. This ensures that the information the standby contains in stDataFiles for a given file matches what the master appliance contains. After the record is inserted into the master appliance's stDataFiles the MySQL database replication feature will ensure the standby appliance receives the new record and there won't be any chance of it conflicting with any existing record because those will have already been deleted by the rebuild command.
In a future LMI version, this message will be suppressed by being moved to debug-level logging.
Issue/Introduction
You may see "SQL peer exec: cluster is not enabled" in LogLogic LMI when executing the rebuild_stdtatafiles command. This article explains what that message means.
Environment
All appliance models and only when HA is disabled
Resolution
No action is necessary for this message unless your appliance is in an HA configuration and you are still seeing this message displayed in the command output. In that case contact TIBCO LogLogic Support.
Feedback
Yes
No
Powered by
