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.