Ralf, > Ralf Ramge wrote: >> Questions: >> >> a) I don't understand why the kernel panics at the moment. the zpool >> isn't mounted on both systems, the zpool itself seems to be fine >> after a >> reboot ... and switching the primary and secondary hosts just for >> resyncing seems to force a full sync, which isn't an option. >> >> b) I'll try a "sndradm -m -r" the next time ... but I'm not sure if I >> like that thought. I would accept this if I replaced the primary host >> with another server, but having to do a 24 TB full sync just >> because the >> replication itself had been disabled for a few minutes would be >> hard to >> swallow. Or did I do something wrong? >> >> > I've answered these questions myself at the meantime (with a nice > employee fo Sun Hamburg giving me the hint). For Google: during a > reverse sync, neither side of the replication is allowed to have the > zpool imported, because after the reverse sync finishes, SNDR enters > replication mode. This renders reverse syncs useless for HA scenarios, > switch primary & secondary instead.
This is close, but not the actual scenario, and actual answer is much better then one would expect. Just prior to issuing a reverse sync, neither side of the replication is allowed to have the, zpool imported. This step is VERY IMPORTANT, since ZFS will detect SNDR replicated writes, and since these writes were not issued by the local ZFS, ZFS will assume these writes are some form of data corruption, since the checksums won't match, and panic the system. Instantly after issuing a reverse sync, zpool(s) on the SNDR primary node can now be imported, without waiting. Although there may be minutes, hours or days of change that need to be replicated from the SNDR secondary volumes to the SNDR primary volumes, SNDR supports on- demand pull of unreplicated changes. This improves one's MTTR (Mean Time To Recover), at the cost of performance for the duration of reverse sync, where the duration is a function of the amount of change that happened while running on the secondary node's volumes. Also any changes made to the primary volume, will be replicated to the secondary volumes during this period, so that the very instant the reverse synchronization operation is complete, both sides of the replica will be identical. > -- > > Ralf Ramge > Senior Solaris Administrator, SCNA, SCSA > > Tel. +49-721-91374-3963 > [EMAIL PROTECTED] - http://web.de/ > > 1&1 Internet AG > Brauerstraße 48 > 76135 Karlsruhe > > Amtsgericht Montabaur HRB 6484 > > Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, > Andreas Gauger, Matthias Greve, Robert Hoffmann, Norbert Lang, > Achim Weiss > Aufsichtsratsvorsitzender: Michael Scheeren > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss Jim Dunham Solaris, Storage Software Group Sun Microsystems, Inc. 1617 Southwood Drive Nashua, NH 03063 Phone x24042 / 781-442-4042 Email: [EMAIL PROTECTED] http://blogs.sun.com/avs _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
