none
FAST ESP : Indexing error RRS feed

  • Question

  • Hi,

    1) Recently we have taken a backup of production environment by copying fixmls from prod cluster to back up cluster.

    But now following error(warning) is coming continuously:

    [2011-09-05 01:05:14]   WARNING   index_producer_0   <Indexing node>       systemmsg   indexer_holder: DocError: Sessino ID 0, operation ID 608313, document ID b1347756d565acbc494898df347fa6f0_<collection>: Aborted document during indexing at fixml file line 3061 column 17. Reason: Summary class 'content2' not found

    On analysing we found out that the index profile in the two environments does not match.

    The difference is an attribute in one field used for lingustics.

    In earlier attempts it worked fine but this time facing errors...

    2) Following is the error talks about some memory footprint

    2011-09-04 23:45:17 Info  memory_check post processor: Memory footprint of 6_876 is 2073 MB, the limit is 1792 MB. Dropping index

    Which memory is been referred here because in our system disk space in Tbs and ram is 50gb+ per node?

    How can we change the footprint?

    Additional info:

    In rtsearchrc config file we have configured to have 10 million docs per logical partition and docsDistributionMaxMB is set to 1.5mb.

    Please help me in understanding the same...

    Thanks



    • Edited by Nitin D Monday, September 5, 2011 5:54 AM
    Monday, September 5, 2011 5:27 AM

Answers

  • Hi Nitin,

    One should be able to copy over the data_fixml from one system to another, perform a resetindex on the target environment, and get search results from the target environment.  When performing this, we recommend that both environments have the same number of indexer columns, the same settings in rtsearchrc.xml, and the same index profile and history of changes to the index profile (via summaryclasses.xml).  The steps to accomplish this would look similar to the below:

    -       Stop feeding to both environments.

    -       Upload index profile used in your source  environment via Admin GUI or bliss -C  in the target environment

    -       Suspend indexing in both environments with indexeradmin –a suspendindexing in both environments.

    -       Observe Admin GUI Matching Engines to verify that Indexer State is suspended

    -       Stop indexer in both environments: nctrl stop indexer

    -       cp %FASTSEARCH%\data\data_fixml from source environment to safe temp location

    -       cp %FASTSEARCH%\etc\config_data\RTSearch\webcluster\summaryclasses.xml from source environment to target environment

    -       cp data_fixml from safe temp location to the data directory (%FASTSEARCH%\data) to your target environment, and maintain column integrity

    Remove files in the target environment:

        %FASTSEARCH%\data\data_fixml\hashFlushed

        %FASTSEARCH%\data\data_fixml\*.dat files. 

        Also %FASTSEARCH%\data\data_index should be empty on your target environment.

    -       In the target environment, edit %FASTSEARCH%\var\indexer.state to contain the value of “reset_index” (no quotes).  This will automatically start a resetindex once the indexer completes initialization.

    -       nctrl start indexer in both environments

    -       Observe Admin GUI Matching Engines in the target environment to verify that Reset Index is in progress

    -       Once the resetindex completes, the data will be searchable.

     

    As noted above, Maintaining column integrity would be required.  If your index profile had differences between the environments, I would recommend using the same index profile, feed the fixml, and make any changes to the index profile afterwards.

     

    To provide additional context, the below general process, as outlined in the Migration Guide on page 16 provides conceptual and procedural details on how to migrate your content from data_fixml without refeeding.  If you would not be using the fixmlfeeding tool, pay specific attention to step 3, and not step 4.

     

    Migration without full re-feed

    Migration of data without full re-feed should typically be used when the index node configuration is changed during the upgrade, that is adding or removing index nodes, or when a re-build of the index is needed (due to certain index profile incompatibilities). Re-indexing from FiXML eliminates the earlier mentioned special procedure (bliss -u) for uploading the index profile. Migration is then carried out by copying FiXML data from the old installation and re-building the index from FiXML, or re-feeding the FiXML (by FiXML Migration) to let it be routed\distributed according to the new route distribution (index dispatching). Re-building index from FiXML is typically much faster than re-feeding and re-processing data from the source.

     

    In order to migrate without full re-feed, these are the pre-requisites:

    • The index profile must be compatible. Refer to Migrating the index profile for details on which index profile changes may be applied without breaking the compatibility.

    • Document processing must be compatible; you must use the same or compatible document processing pipelines. See Document Processing Migration for details. It is possible to accommodate some incompatible changes to index profile or document processing by creating a custom configuration file for the FiXML conversion in the Migration pipeline stage. This is not covered by this guide. Contact FAST Global Services if this might be needed.

    Note: Follow step 3. or 4. depending on how you decide to migrate and re-build the index. Steps 5. And 6. are common.

    1. Install the admin node of the new ESP 5.2 installation and migrate the configuration to it, as described in Migrating configuration: overview.

    2. Follow Migrating index: overview to set up the new ESP 5.2 indexer nodes with an empty index.

    3. This step describes how to migrate an indexer node when re-building the index from FiXML (not re-feeding or re-distributing the FiXML).

    a) Stop the indexer process on your old ESP 5 node.

    nctrl stop indexer

    b) Save FiXML data from the old ESP 5 node.

    The data to be copied is %FASTSEARCH%\data\data_fixml. Move the directory or copy the content to a safe temporary location.

    c) Uninstall the old ESP 5 indexer node.

    This can be postponed if the new installation does not replace the old one on the same physical node.

    d) Install the ESP 5.2 indexer node with index profile from the old ESP 5 system. Do not start it. (You may also upload the index profile after start-up, but before copying the FiXML).

    e) If new summary class <content> fields have been added to the old, default ESP 5.0 index profile, the file %FASTSEARCH%\etc\config_data\RTSearch\webcluster\summaryclasses.xml must be copied to the new ESP 5.2 admin node before the ESP 5.0 index profile is deployed. See Migrating the index profile for further info.

    f) Restore the index in the new ESP 5.2 indexer node.

    Copy or move data_fixml from the temporary location to the data directory (%FASTSEARCH%\data) in the new ESP 5.2 node. Remove the %FASTSEARCH%\data\data_fixml\hashFlushed and the contents of data_index.

    g) Start the new ESP 5.2 indexer node.

    This will trigger a resetindex operation, and the index is rebuilt from FiXML.

    4. This step describes how to migrate an indexer node when using the 'FiXML Migration Tool' to re-feed (and re-distribute, if planned) the FiXML.

    a) Stop the indexer process on the old ESP 5 node.

    nctrl stop indexer

    b) Save FiXML data from the old ESP 5 node.

    The data to be copied is %FASTSEARCH%\data\data_fixml. Move the directory or copy the content to a safe temporary location.

    c) Uninstall the old ESP 5 indexer node.

    This can be postponed if the new installation does not replace the old one on the same physical node.

    d) Install the ESP 5.2 indexer node with the ESP 5.2 index profile, using the same type of index profile as in the old ESP 5 installation (standard, lemmatization or geo). Do not start the indexer note yet.

    e) Start the indexer node. Set it in indexing suspended mode: indexeradmin suspendindexing

    f) Re-feed FiXML data.

    Use the fixmlfeeder to re-feed FiXML from the saved data_fixml directories. See Migrating FiXML data for detailed procedure.

    g) Resume indexing.

    indexeradmin -a resumeindexing

    5. Migrate the administrative data (user, group, search profile) as described in Migrating Administrative Data.

    6. Migrate remaining search nodes and switch search over to the new index as described in Migrating search: overview.

     

    Let us know your results.

     

    Thanks!

    Rob Vazzana | Sr Support Escalation Engineer | US Customer Service & Support

    Customer Service & Support                          Microsoft | Services

    Tuesday, September 20, 2011 4:04 PM
    Moderator

All replies

  • Hi Nitin,

    1) Can you clarify your question? If the index profiles do not match up between the rigs, you cannot expect copying FIXML to work either. The FIXML reflects the index profile of the solution it was generated on.

    2) Are you sure docsDistributionMaxMB is set to 1.5MB? That sounds extremely low. If at all configured, this value is usually way way higher. It will limit the amount of documents on a single partition. E.g., settings this parameter to 1000 (MB) will limit each partition to hold at max 100000 documents (assuming an average document size 10KB.

    Regards,

    Marcus

     


    Marcus Johansson | Search Nerd | comperiosearch.com | linkedin.com/in/marcusjohansson
    Friday, September 9, 2011 9:37 AM
  • Hi,

    1) the difference in the index profiles is only one field where we have enabled the lemmatization in it.

    2) docsDistributionMaxMB is set to 1536MB.

    Thanks


    Nitin
    Monday, September 12, 2011 9:47 AM
  • Hi Nitin,

    One should be able to copy over the data_fixml from one system to another, perform a resetindex on the target environment, and get search results from the target environment.  When performing this, we recommend that both environments have the same number of indexer columns, the same settings in rtsearchrc.xml, and the same index profile and history of changes to the index profile (via summaryclasses.xml).  The steps to accomplish this would look similar to the below:

    -       Stop feeding to both environments.

    -       Upload index profile used in your source  environment via Admin GUI or bliss -C  in the target environment

    -       Suspend indexing in both environments with indexeradmin –a suspendindexing in both environments.

    -       Observe Admin GUI Matching Engines to verify that Indexer State is suspended

    -       Stop indexer in both environments: nctrl stop indexer

    -       cp %FASTSEARCH%\data\data_fixml from source environment to safe temp location

    -       cp %FASTSEARCH%\etc\config_data\RTSearch\webcluster\summaryclasses.xml from source environment to target environment

    -       cp data_fixml from safe temp location to the data directory (%FASTSEARCH%\data) to your target environment, and maintain column integrity

    Remove files in the target environment:

        %FASTSEARCH%\data\data_fixml\hashFlushed

        %FASTSEARCH%\data\data_fixml\*.dat files. 

        Also %FASTSEARCH%\data\data_index should be empty on your target environment.

    -       In the target environment, edit %FASTSEARCH%\var\indexer.state to contain the value of “reset_index” (no quotes).  This will automatically start a resetindex once the indexer completes initialization.

    -       nctrl start indexer in both environments

    -       Observe Admin GUI Matching Engines in the target environment to verify that Reset Index is in progress

    -       Once the resetindex completes, the data will be searchable.

     

    As noted above, Maintaining column integrity would be required.  If your index profile had differences between the environments, I would recommend using the same index profile, feed the fixml, and make any changes to the index profile afterwards.

     

    To provide additional context, the below general process, as outlined in the Migration Guide on page 16 provides conceptual and procedural details on how to migrate your content from data_fixml without refeeding.  If you would not be using the fixmlfeeding tool, pay specific attention to step 3, and not step 4.

     

    Migration without full re-feed

    Migration of data without full re-feed should typically be used when the index node configuration is changed during the upgrade, that is adding or removing index nodes, or when a re-build of the index is needed (due to certain index profile incompatibilities). Re-indexing from FiXML eliminates the earlier mentioned special procedure (bliss -u) for uploading the index profile. Migration is then carried out by copying FiXML data from the old installation and re-building the index from FiXML, or re-feeding the FiXML (by FiXML Migration) to let it be routed\distributed according to the new route distribution (index dispatching). Re-building index from FiXML is typically much faster than re-feeding and re-processing data from the source.

     

    In order to migrate without full re-feed, these are the pre-requisites:

    • The index profile must be compatible. Refer to Migrating the index profile for details on which index profile changes may be applied without breaking the compatibility.

    • Document processing must be compatible; you must use the same or compatible document processing pipelines. See Document Processing Migration for details. It is possible to accommodate some incompatible changes to index profile or document processing by creating a custom configuration file for the FiXML conversion in the Migration pipeline stage. This is not covered by this guide. Contact FAST Global Services if this might be needed.

    Note: Follow step 3. or 4. depending on how you decide to migrate and re-build the index. Steps 5. And 6. are common.

    1. Install the admin node of the new ESP 5.2 installation and migrate the configuration to it, as described in Migrating configuration: overview.

    2. Follow Migrating index: overview to set up the new ESP 5.2 indexer nodes with an empty index.

    3. This step describes how to migrate an indexer node when re-building the index from FiXML (not re-feeding or re-distributing the FiXML).

    a) Stop the indexer process on your old ESP 5 node.

    nctrl stop indexer

    b) Save FiXML data from the old ESP 5 node.

    The data to be copied is %FASTSEARCH%\data\data_fixml. Move the directory or copy the content to a safe temporary location.

    c) Uninstall the old ESP 5 indexer node.

    This can be postponed if the new installation does not replace the old one on the same physical node.

    d) Install the ESP 5.2 indexer node with index profile from the old ESP 5 system. Do not start it. (You may also upload the index profile after start-up, but before copying the FiXML).

    e) If new summary class <content> fields have been added to the old, default ESP 5.0 index profile, the file %FASTSEARCH%\etc\config_data\RTSearch\webcluster\summaryclasses.xml must be copied to the new ESP 5.2 admin node before the ESP 5.0 index profile is deployed. See Migrating the index profile for further info.

    f) Restore the index in the new ESP 5.2 indexer node.

    Copy or move data_fixml from the temporary location to the data directory (%FASTSEARCH%\data) in the new ESP 5.2 node. Remove the %FASTSEARCH%\data\data_fixml\hashFlushed and the contents of data_index.

    g) Start the new ESP 5.2 indexer node.

    This will trigger a resetindex operation, and the index is rebuilt from FiXML.

    4. This step describes how to migrate an indexer node when using the 'FiXML Migration Tool' to re-feed (and re-distribute, if planned) the FiXML.

    a) Stop the indexer process on the old ESP 5 node.

    nctrl stop indexer

    b) Save FiXML data from the old ESP 5 node.

    The data to be copied is %FASTSEARCH%\data\data_fixml. Move the directory or copy the content to a safe temporary location.

    c) Uninstall the old ESP 5 indexer node.

    This can be postponed if the new installation does not replace the old one on the same physical node.

    d) Install the ESP 5.2 indexer node with the ESP 5.2 index profile, using the same type of index profile as in the old ESP 5 installation (standard, lemmatization or geo). Do not start the indexer note yet.

    e) Start the indexer node. Set it in indexing suspended mode: indexeradmin suspendindexing

    f) Re-feed FiXML data.

    Use the fixmlfeeder to re-feed FiXML from the saved data_fixml directories. See Migrating FiXML data for detailed procedure.

    g) Resume indexing.

    indexeradmin -a resumeindexing

    5. Migrate the administrative data (user, group, search profile) as described in Migrating Administrative Data.

    6. Migrate remaining search nodes and switch search over to the new index as described in Migrating search: overview.

     

    Let us know your results.

     

    Thanks!

    Rob Vazzana | Sr Support Escalation Engineer | US Customer Service & Support

    Customer Service & Support                          Microsoft | Services

    Tuesday, September 20, 2011 4:04 PM
    Moderator