Open-source serverless enterprise CMS. Includes a headless CMS, page builder, form builder, and file manager. Easy to customize and expand. Deploys to AWS.
With this PR, we're improving the disablement and restoration of ES indexing settings. Having these improvements would also be useful for previous data migrations, but for now, we won't be porting them to those. We'll start thinking about it when an actual need arises.
First of all, when disabling indexing on an index, we no longer set the number_of_replicas to zero. From this doc:
This will temporarily put your index at risk since the loss of any shard will cause data loss, but at the same time indexing will be faster since ...
So, because there is risk involved, we decided to simply not fiddle with this setting.
Furthermore, we've addressed an index restoration issue. Prior to this PR, when doing a restoration, previously retrieved ES index would be used. Which is OK, because this way we ensure the original index settings are applied back to the inedx.
But, if a user stopped the data migration manually, and then rerun it, then the restoration step would incorrectly again set "disable indexing" settings. This is because it would use the index settings that were retrieved at the beginning of the new run, which, because the previous run has been manually stopped, still contain refresh_interval: -1. Ultimately, this setting would be applied when restoring index settings, effectively leaving the "indexing: disabled" setting still active.
Changes
With this PR, we're improving the disablement and restoration of ES indexing settings. Having these improvements would also be useful for previous data migrations, but for now, we won't be porting them to those. We'll start thinking about it when an actual need arises.
First of all, when disabling indexing on an index, we no longer set the
number_of_replicasto zero. From this doc:So, because there is risk involved, we decided to simply not fiddle with this setting.
Furthermore, we've addressed an index restoration issue. Prior to this PR, when doing a restoration, previously retrieved ES index would be used. Which is OK, because this way we ensure the original index settings are applied back to the inedx.
But, if a user stopped the data migration manually, and then rerun it, then the restoration step would incorrectly again set "disable indexing" settings. This is because it would use the index settings that were retrieved at the beginning of the new run, which, because the previous run has been manually stopped, still contain
refresh_interval: -1. Ultimately, this setting would be applied when restoring index settings, effectively leaving the "indexing: disabled" setting still active.How Has This Been Tested?
Manually. Relying on existing Jest tests.
Documentation
Changelog.