[
https://issues.apache.org/jira/browse/JAMES-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-3631.
---------------------------------
Resolution: Fixed
> Migration strategy for Cassandra mailRepository
> -----------------------------------------------
>
> Key: JAMES-3631
> URL: https://issues.apache.org/jira/browse/JAMES-3631
> Project: James Server
> Issue Type: Improvement
> Components: cassandra, MailStore & MailRepository
> Affects Versions: master
> Reporter: Benoit Tellier
> Priority: Major
> Fix For: 3.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h2. Context?
> The count of Cassandra table impact overall performance.
> For people collocating several James cluster on distinct Cassandra keyspace
> their counts can quickly add up.
> Thus sanitizing schema transitions, in addition to clean code up also enable
> to keep table count low.
> h2. Why?
> In 2018 we migrated the way to structure MailRepository, and supplied a
> fallback mechanism, without providing means to migrate them from the old
> schema to the new.
> An easy mean is to rely on reprocessing:
> - In mailetcontainer.xml define an orphan processor with just a ToRepository
> mailet for the processor you wishes to migrate.
> - Then trigger a full reprocessing.
> - Emails will be re-added but in v2
> Doing the upgrade with empty mail repository works too.
> People adopting distributed James after version 3.4.0 are not impacted.
> h2. What to do from there?
> - Document commands to audit if a migration is needed
> - Document the migration process (prior to an upgrade)
> - Document that after the upgrade the table can be dropped.
> - Drop the table off James code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
