elastic/elasticsearch

CCR automatically replicates all x-pack index settings

Open

#51,972 opened on Feb 6, 2020

View on GitHub
 (13 comments) (0 reactions) (0 assignees)Java (76,700 stars) (25,882 forks)batch import
:Distributed/CCR>bugTeam:Distributedhelp wanted

Description

CCR is deliberate about which index settings it copies:

https://github.com/elastic/elasticsearch/blob/da20957e815d9370142738be9e402727f36b9857/x-pack/plugin/ccr/src/main/java/org/elasticsearch/xpack/ccr/action/TransportResumeFollowAction.java#L455-L460

In fact, there is a test to ensure that if any index setting is added, the setting is either deliberately marked as replicated, or is added to the list of non-replicated settings:

https://github.com/elastic/elasticsearch/blob/698b1e97e78cdec26f1b2f971dd0d5e79e8ac47e/x-pack/plugin/ccr/src/test/java/org/elasticsearch/xpack/ccr/action/TransportResumeFollowActionTests.java#L198-L222

Alas, there is some oversight here which relates to index settings registered in x-pack (e.g., ILM index-level settings such as the index policy). This means that today, all such settings are replicated from the leader to the follower. This can lead to issues on the follower (e.g., explicit issues such as if the ILM policy does not exist in the local cluster, or implicit issues such as if the ILM policy does exist in the local cluster, but it's not the one that user wanted to have used on the follower index).

Contributor guide