WebSphere Commerce search considerations for dual cell environments

The WebSphere Commerce search server index and database on the staging environment need to be synchronized with the production cell.
On the Staging environment, once the tasks are approved and a Solr rebuild is triggered, the updated items in the cache are invalidated, the database is updated, and Solr files are also updated. Consider the following diagram:

When Solr files and the database on the staging environment are updated, they need to be synchronized with the production cells.
When you set up your dual cell environment, there are three main considerations to synchronizing WebSphere Commerce search in your productions cells:

Configuring WebSphere Commerce search

There are different ways to configure WebSphere Commerce search repeaters. One option is to set one search node in each production cell as a repeater, and the other search nodes as its subordinates (slaves). By using multiple repeaters, you avoid updating each subordinate node every time there is an update from the Staging environment. The search node in the Staging environment acts as a master to update the search repeater in Cell1. Then, Cell1 acts as a master to update the search repeater in Cell2. All subordinate nodes poll updates from their respective repeater. For large environments, having two repeaters improves performance.

The following diagram depicts one repeater per cell but you can modify the topology to suit your environment:

For more information about creating repeaters, see Replicating WebSphere Commerce Search with the repeater.

Synchronizing customized data and Solr files between the Staging and Production environments

After tasks are approved, an administrator must run the following utilities on the Staging environment:
  1. stagingprop utility to update the production database
  2. fileprop utility sends all new files and changed files to the production environment
  3. indexprop utility to update Solr files and send the updated Solr files to the repeater

Applying emergency fixes with Quick Publish

If you need to apply emergency fixes, you can use Quick Publish in workspaces. For more information about setting up Quick Publish, see step 3 in Replicating WebSphere Commerce Search with the repeater.
If you set up the search repeaters as depicted in Configuring WebSphere Commerce search, complete the following steps to ensure that both cells are updated with the emergency fix:
  1. In the production server database, update the SRCHCONF and SRCHCONFEXT tables by setting the SearchServerPort and SearchServerName values in the CONFIG column to Cell1's repeater port and host name respectively.
  2. Update the WebSphere Commerce DB2 Publish DataSource instance_name datasource on the staging environment to point to the production database.
If configured properly, when the tasks are approved, the production database and the staging database are updated at the same time. The UpdateSearchIndex job on cell1 creates the Solr delta index in the repeater, which is sent to its subordinates, and also to the repeater in cell2. Then, the repeater in cell2 sends the Solr delta index to the subordinates of cell2. The DynaCacheInvalidation job will invalidate all the updated items from the cache. For more information about setting up dynamic caching, see Dynamic caching considerations for dual cell environments.