On Mon, Nov 12, 2018 at 2:46 PM Hector Martin <hec...@marcansoft.com> wrote:
> On 10/11/2018 06:35, Gregory Farnum wrote: > > Yes, do that, don't try and back up your monitor. If you restore a > > monitor from backup then the monitor — your authoritative data source — > > will warp back in time on what the OSD peering intervals look like, > > which snapshots have been deleted and created, etc. It would be a huge > > disaster and probably every running daemon or client would have to pause > > IO until the monitor generated enough map epochs to "catch up" — and > > then the rest of the cluster would start applying those changes and > > nothing would work right. > > Thanks, I suspected this might be the case. Is there any reasonable safe > "backwards warp" time window (that would permit asynchronous replication > of mon storage to be good enough for disaster recovery), e.g. on the > order of seconds? I assume synchronous replication is fine (e.g. RAID or > DRBD configured correctly) since that's largely equivalent to local > storage. I'll probably go with something like that for mon durability. > Unfortunately there really isn't. Any situation in which a monitor goes back in time opens up the possibility (even likelihood!) that updates which directly impact data services can disappear and cause issues. Synchronous replication is fine, although I'm not sure there's much advantage to doing that over simply running another monitor in that disk location. -Greg > > > Unlike the OSDMap, the MDSMap doesn't really keep track of any > > persistent data so it's much safer to rebuild or reset from scratch. > > -Greg > > Good to know. I'll see if I can do some DR tests when I set this up, to > prove to myself that it all works out :-) > > -- > Hector Martin (hec...@marcansoft.com) > Public Key: https://marcan.st/marcan.asc >
_______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
