Troubleshooting Secondary Index Encoding Errors

This section describes how to locate secondary index encoding errors in log files, and then resolve them.

Unresolved secondary index encoding errors can result in queries returning incomplete results. See Secondary Index Encoding Error for details.

To troubleshoot secondary index encoding errors, follow these steps:

  1. Determine whether any table has index encoding alarms by using one of the following two options:
    • Run the following grep command, searching for the strings index and encoding in the mfs.log-5 file:
      # grep -i "index.*encoding" /opt/mapr/logs/mfs.log-5
      2018-07-10 11:06:07,7042 INFO DB db/repl/araggregator.cc:524 Table 2050.43.262440 hit index row-key encoding error
      2018-07-10 11:06:07,7042 INFO DB db/repl/araggregator.cc:914 Raising alarm VOLUME_ALARM_TABLE_INDEX_ENCODING_ERROR for volume 195503497

      The fid, 2050.43.262440, in the sample output indicates the table corresponding to the alarm. If you are not sure which table this corresponds to, you can convert the fid to a table path by following the instructions at Converting fid and volid.

    • Check for any table index encoding alarms in the MapR Control System, as described at Viewing Active Table Replication Alarms.

      The alarm details indicate the table corresponding to the alarm.

  2. Find the index on the table from step 1 that is causing the error.

    Run dbshell indexscan with --mode set to err on each index to see the index's error output. You need to run the command multiple times if a table has multiple indexes with errors.

    For example, if table1 has three secondary indexes and all three secondary indexes have errors, you must run indexscan three times:
    indexscan /table1 --indexname index1 --mode err 
    indexscan /table1 --indexname index2 --mode err 
    indexscan /table1 --indexname index3 --mode err
    The following example shows error output from running the dbshell indexscan command:
    maprdb root:> indexscan /IndexEncodingErrorAlarmsTest1/tab1 --indexname idx1 --mode err 
    {"_id":"1","$ERROR":"Index field 3: MAPS_ARE_NOT_SUPPORTED"} 
    {"_id":"10","$ERROR":"Index field 2: ARRAYS_ARE_NOT_SUPPORTED"} 
    {"_id":"100","$ERROR":"Index field 1: INVALID_CAST"} 
    {"_id":"1000","$ERROR":"Index field 4: MAPS_ARE_NOT_SUPPORTED"}
  3. Address the identified errors by attempting the following suggested resolutions:
    Error Suggested Resolutions
    KEY_TOO_LONG: The collective size of the index key is limited to less than 32 KB.
    • Reinsert the row in the JSON table so the collective size of all the indexed fields is less than 32 KB.
    • Redesign the secondary index so fields with large values are included fields instead of indexed fields.
    • Reduce the number of indexed fields in the secondary index.
    ARRAYS_ARE_NOT_SUPPORTED: Arrays are not allowed in an indexed field.
    • Reinsert the row in the JSON table so the values of indexed fields are scalar values.
    • Redesign the secondary index so the fields that have nonscalar values are included fields instead of indexed fields.
    MAPS_ARE_NOT_SUPPORTED: Maps are not allowed for indexed fields.
    • Reinsert the row in the JSON table so the values of indexed fields are scalar values.
    • Redesign the secondary index so the fields that have nonscalar values are included fields instead of indexed fields.
    INVALID_CAST: An error was encountered applying the CAST function on an indexed field.
    • Verify that you have specified the correct types when using the CAST function with indexed fields.

    • If the types are correct, reinsert the row in the JSON table so the values of indexed fields can be cast to the specified type.

      See Using Casts in Secondary Indexes.