-
Bug
-
Resolution: Fixed
-
High
-
6.4.14, 7.2.2, 7.2.9, 7.3.7, 7.12.1
-
6.04
-
53
-
Severity 2 - Major
-
38
-
Summary
When starting a node that has outdated indexes (meaning: not having the latest index operation in the cluster replicated), it is supposed to automatically restore the indexes from the node that registered the latest index operation. However, if that node is unavailable or if that node never wrote a row to replicatedindexoperation, this will fail and the node will not have the latest index updates. See related JRASERVER-66550
Expected Behavior
Copy indexes from another node that has healthy indexes (have updated the indexes with latest operation).
Actual Behavior
The index restore fails and the below message is registered on the logs of the node that claimed the index restore request.
2016-09-30 16:25:33,487 ClusterMessageHandlerServiceThread:thread-1 INFO [jira.index.ha.DefaultIndexCopyService] Index backup started. Requesting node: node3 2016-09-30 16:25:33,488 ClusterMessageHandlerServiceThread:thread-1 WARN [jira.index.ha.DefaultIndexCopyService] Index backup failed - latest index operation not found. Requesting node: node3
Steps to Reproduce
- Setup a new JIRA instance, which will be node1;
- Create a new project and some issues.
- Setup another JIRA instance, which will be node2. This node will restore the index from node1. Do not create or modify any issues in this node.
- Setup yet another JIRA instance, which will be node3. This node might attempt to restore the index from node2. (it depends which node claims the request first)
- node2 will fail to create an index snapshot as there are no rows in replicatedindexoperation having node_id = node2.
Note
Problem is node2 shouldn't reply to the index request since it doesn't satisfy sanity check, see JRASERVER-66550.
That will leave only node1 as a potential index provider, which fixes the problem.
Workaround
option1
On the new node in the cluster (node 3, in this case), manually copy the indexes from node 2:
- Go to Administration > System > Indexing;
- Under Copy the Search Index from another node, select node 2 and copy;
Make sure the indexes on the chosen node are healthy by looking at the Indexing health check under the Administration > System > Support Tools > Health Checks section of that node.
option2
- Touch any issues at the newly created node, so it will pass sanity check and will be able to share index.
option3
- Perform a re-index operation on every new node brought up.
- depends on
-
JRASERVER-66550 JIRA Datacenter - Add additional Lucene index checks before propagating index to other nodes
- Gathering Interest
- is related to
-
JRASERVER-72125 Index replication service is paused indefinitely after failing to obtain an index snapshot from another node
- Closed
- is resolved by
-
ASCI-8 Loading...
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
- relates to
-
DCKUBE-628 Loading...