Yes, we replicate all operations including deletes. The main use-case for uni-directional XDCR is “hot spare” system, where destination server acts as a failsafe for the source cluster. So you will need to think of a custom solution here.
I am not sure how much you care about consistency of data but if you wanted to get creative, you could try is to use the aggregation system setup with a trick. The XDCR topology looks like this; A accumulates all data from many source clusters that produce none overlapping data: A <- B, A <- C, A<- D and so on… So keys are unique across all clusters and data on A is a full union of B, C, D and more.
Here is what you can try in your case;
- Create bucket per day: ‘day1’, ‘day2’, ‘day3’ etc on source cluster. (per day because your expiration period is 24 hours).
- In your app, add data to the new bucket every day and set up XDCR from the buckets ‘dayN’ to the destination bucket ‘all_days’. So on your second day, you are writing to day2 bucket and no longer writing to day1 bucket.
- Once all data in day1 is replicated to ‘all_days’ destination bucket, delete the XDCR replication from ‘day1’ to ‘all_data’ - this won’t delete data from ‘all_day’ bucket, it will simply stop replicating from ‘day1’ bucket at that point. drop and recreate a new/empty day1 bucket.
- this ensures all_data bucket continues to accumulate data while your source buckets (‘dayN’) gets cleaned up at a regular interval.
This is just an example and I am sure you can come up with other methods with similar effect. But make sure to test it end to end to ensure it does work in your case, as there are many assumptions I am making about your app: For example; this only works if key’s you are using are perpetually unique and you never reuse them between ‘dayN’ buckets. Or that you never update older data after a certain point (your expiring data won’t get updated but there may be other documents/values in your system without expiry etc etc… So use the technique with a lot of caution.