You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by bt...@apache.org on 2019/05/28 04:00:38 UTC
[james-project] 11/11: JAMES-2766 Upgrading to ElasticSearch 6.7
This is an automated email from the ASF dual-hosted git repository.
btellier pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/james-project.git
commit 8df6ddcb7e239e8284a8abcf1a60535002f96b52
Author: Benoit Tellier <bt...@linagora.com>
AuthorDate: Mon May 27 10:09:51 2019 +0700
JAMES-2766 Upgrading to ElasticSearch 6.7
We propose to strategies:
- A simple one that compromise search accuracy
- Another one that minimize search inconsistencies but requires more operations.
---
upgrade-instructions.md | 47 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/upgrade-instructions.md b/upgrade-instructions.md
index 1450d98..4399a14 100644
--- a/upgrade-instructions.md
+++ b/upgrade-instructions.md
@@ -14,6 +14,53 @@ Note: this section is in progress. It will be updated during all the development
Changes to apply between 3.3.x and 3.4.x will be reported here.
+Change list:
+
+ - [Upgrade to ElasticSearch 6.7](#upgrade-to-elasticsearch-6.7)
+
+#### Upgrade to ElasticSearch 6.7
+
+Date: 27/05/2019
+
+SHA-1: bbdf88e56d7a22fe92e1360ef563004f3bc0dd98
+
+JIRA: https://issues.apache.org/jira/browse/JAMES-2766
+
+Concerned products: (experimental) Cassandra-guice products.
+
+In version 3.3.0 indexing for the Cassandra product was handled using ElasticSearch 2.2 released on the 31 march 2016. Some major upgrades had been included in recent ElasticSearch version.
+
+Note that ElasticSearch APIs had been undergoing some major changes, making a smooth migration hard to provide. We proposed 2 migration strategies. A
+simple one leading to major search inconsistencies in the process, and another one mitigating these inconsistencies (but getting rid of them).
+
+##### Simple strategy
+
+Procedure:
+ - From a running James 3.3.0 cluster connected to a running ElacticSearch 2.2 cluster
+ - Start an empty ElasticSearch 6.7 cluster
+ - Shutdown James 3.3.0 cluster and start a James 3.4.0 cluster connected to ElasticSearch 6.7
+ - Search result will then be empty and thus innacurate
+ - Thus trigger a [Full ReIndexing](https://james.apache.org/server/manage-webadmin.html#ReIndexing_all_mails) to restore search consistency.
+
+Keep in mind that full reIndexing needs to process all users email and thus can be slow.
+
+Obviously this approach trades search consistency against ease of migration.
+
+If search consistency during the migration is important for you, consider the next approach
+
+##### Strategy for minimizing search inconsistency during the migration
+
+Procedure:
+ - From a running James 3.3.0 cluster connected to a running ElacticSearch 2.2 cluster
+ - Start an empty ElasticSearch 6.7 cluster
+ - Start a James 3.4.0 cluster connected to ElasticSearch 6.7 cluster as well as the Cassandra source of trust database. Traffic should be directed to the James 3.3.0 cluster.
+ - Trigger an offline [Full ReIndexing](https://james.apache.org/server/manage-webadmin.html#ReIndexing_all_mails) on the James 3.4.0 cluster
+ - Once done, direct the traffic to the James 3.4.0 cluster, and dispose the James 3.3.0 cluster as well as the ElasticSearch 2.2 cluster
+ - Search result will omit changes that took place during the switching process (starting from the reIndexing start)
+ - Thus trigger a [Full ReIndexing](https://james.apache.org/server/manage-webadmin.html#ReIndexing_all_mails) to restore search consistency.
+
+Keep in mind that full reIndexing needs to process all users email and thus can be slow.
+
## 3.3.0 version
Changes to apply between 3.2.0 and 3.3.0 had been reported here.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org