[jira] [Closed] (ARTEMIS-541) Optimize live/backup replication after failback

["clebert suconic (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ARTEMIS-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

clebert suconic closed ARTEMIS-541.
-----------------------------------
    Resolution: Won't Fix

It's not that simple... The adds and deletes could be from a very old journal.


It's already a great advantage to be able to run the broker as you make the copy. nothing is stopping the broker as you copy it.. it's not possible to make the comparisson of what's missing from the old backup, hence impossible to only send the diffs.


You would need to send the whole journal anyways to make any delta comparisons.  Or at least read and send IDs.. which would be a risky process..

For that reason I'm rejecting this.

> Optimize live/backup replication after failback
> -----------------------------------------------
>
>                 Key: ARTEMIS-541
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-541
>             Project: ActiveMQ Artemis
>          Issue Type: New Feature
>          Components: Broker
>    Affects Versions: 1.3.0
>            Reporter: Miroslav Novak
>
> Currently if there is master/slave pair configured using replicated journal then after each failback when master is starting, it copies the whole journal directory from slave.
> This seems to ineffective as master might have significant part of backups journal before it failed. 
> If only differences between journals would be transfered then it would be effective especially in case when failback is completed and master starts to synchronize the whole journal back to slave. It copies the whole journal to backup again which is almost the same. This would greatly speed up synchronization of slave and safe network bandwidth.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)