I don't think "giving up" on updating is a good idea, because it may cause danger that
account will never be reclaimed when all container-server fail to update and give up.
> As part of this process, the reported_*_timestamps are set to zero (see container.backend._newid).
I think this is the root of this problem.
When database is completely rsynced from container-server B to container-server A,
we don't have to reset reported_*_timestamp at container-server A
because container-server B have updated the account.
# We have to reset it only after merging databases.
I think removing that reset processing is a solution for this problem.
It stops container-server A from trying this unnessesory updating after replication,
and then replicated container will be reclaimed normally.
I don't think "giving up" on updating is a good idea, because it may cause danger that
account will never be reclaimed when all container-server fail to update and give up.
> As part of this process, the reported_ *_timestamps are set to zero (see container. backend. _newid) . *_timestamp at container-server A
I think this is the root of this problem.
When database is completely rsynced from container-server B to container-server A,
we don't have to reset reported_
because container-server B have updated the account.
# We have to reset it only after merging databases.
I think removing that reset processing is a solution for this problem.
It stops container-server A from trying this unnessesory updating after replication,
and then replicated container will be reclaimed normally.