You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With 2.9.0 release, there are lot of enhancements going in for segment replication[1][2] feature (went GA in 2.7.0), we need to ensure different plugins are compatible with current state of this feature. Previously, we ran tests on plugin repos to verify this compatibility but want plugin owners to be aware of these changes so that required updates (if any) can be made
What changed
1. Refresh policy behavior
RefreshPolicy.IMMEDIATE will only refresh primary shards but not replica shards immediately. Instead post refresh, primary will start a round of segment replication to update the replica shard copies leading to eventual consistency.
RefreshPolicy.WAIT_UNTIL ensures the indexing operation is searchable in your cluster i.e. RAW (Read after write guarantee). With segment replication, this guarantee is not promised due to delay in replica shared updates from asynchronous background refreshes.
2. Refresh lag on replicas
With segment replication, there is inherent delay in documents to be searchable on replica shard copies. This is due to the fact that replica shard copies over data (segment) files from primary. Thus, compared to document replication, there will be on average increase in amount of time the replica shards are consistent with primaries.
3. System/hidden indices support
With opensearch-project/OpenSearch#8200, system and hidden indices are now supported with SEGMENT replication strategy. We need to ensure there are no bottlenecks which prevents system/hidden indices with segment replication.
Next steps
With segment replication strong reads are not guaranteed. Thus, if the plugin needs strong reads guarantees specially as alternative to change in behavior of refresh policy and lag on replicas (point 1 and 2 above), we need to update search requests to target primary shard only. With opensearch-project/OpenSearch#7375, core now supports primary shards only based search. Please follow documentation for examples and details
Open questions
In case of any questions or issues, please post it in core issue
Hi @dreamer-89 , the ml-commons-dashboards doesn't use any indices directly. This plugin depend on the ml-commons plugin. The ml-commons-dashboards plugin call the ml-commons API in the front end. I found there is an issue in the ml-commons repository. I think there won't be any compatibility problem if the ml-commons is OK for segment replication.
Hi @dreamer-89 , the ml-commons-dashboards doesn't use any indices directly. This plugin depend on the ml-commons plugin. The ml-commons-dashboards plugin call the ml-commons API in the front end. I found there is an issue in the ml-commons repository. I think there won't be any compatibility problem if the ml-commons is OK for segment replication.
Thanks @wanglam for the update. Closing this issue since this repo does not use indices directly and relies on ml-commons plugin.
Summary
With 2.9.0 release, there are lot of enhancements going in for segment replication[1][2] feature (went GA in 2.7.0), we need to ensure different plugins are compatible with current state of this feature. Previously, we ran tests on plugin repos to verify this compatibility but want plugin owners to be aware of these changes so that required updates (if any) can be made
What changed
1. Refresh policy behavior
2. Refresh lag on replicas
With segment replication, there is inherent delay in documents to be searchable on replica shard copies. This is due to the fact that replica shard copies over data (segment) files from primary. Thus, compared to document replication, there will be on average increase in amount of time the replica shards are consistent with primaries.
3. System/hidden indices support
With opensearch-project/OpenSearch#8200, system and hidden indices are now supported with
SEGMENT
replication strategy. We need to ensure there are no bottlenecks which prevents system/hidden indices with segment replication.Next steps
With segment replication strong reads are not guaranteed. Thus, if the plugin needs strong reads guarantees specially as alternative to change in behavior of refresh policy and lag on replicas (point 1 and 2 above), we need to update search requests to target primary shard only. With opensearch-project/OpenSearch#7375, core now supports primary shards only based search. Please follow documentation for examples and details
Open questions
In case of any questions or issues, please post it in core issue
Reference
[1] Design
[2] Documentation
The text was updated successfully, but these errors were encountered: