Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Am Dienstag, 22. März 2005 17:48 schrieb Filip Sergeys:
> Hello,
>
> Maybe my input can help you convince. Indeed mounting read only does
> come in very handy for database logfiles.
>
> This is the situation:
> A masterdatabase which is online
> A slavedatabase which is in standby
>
> In normal operations:
> ------------------------
> The masterdatabase writes duplexed log files and archived log files to
> the primary drbd device.
> At night the slavedatabase "wakes up" mounts the secondary drbd device
> read only and applies the past 24 hours of changes captured in the
> archived and the online redo log files. When done, the database goes
> back to standby and the device is umounted.
> To be more precise, in reality, I mount the device, copy the changes
> since last night to a local device, unmount, and then work with the
> local copies. The reason? I don't know how the slavedatabase would react
> if the online redologfiles changed will rolling forward.
> So far this could also be done with NFS
>
> When a failure happens on the masterdatabase and it goes down:
> ---------------------------------------------------------------------------
> the slavedatabase kicks in (via heartbeat) mounts the drbd device in
> primary, applies the changes since midnight and fires up in online
> state.
> This could not be done with NFS because you wouldn't have access
> anymore. rsync is not an option either because you need the committed
> changes up to the very last second.
>
> I think this is a very common setup and drbd is a magnificent tool to
> reach the goal for this.
> So hope this is convincing enough ;)
>
This reasoning is exactly the reason why we prohibit mounting the secondary.
I assume that you use a filesystem like ext3, XFS or reiserfs.
For the short time you mount it on the seconary, the primary may
modify it...
Just consider this... the FS on the secondary reads an inode...,
then the FS is modified by the primary, then the FS on the secondary
wants to read the data blocks, that are referenced by the inode....
But in the meantime these data blocks where relocated by the other machine...
My experiences are:
- ext2/ext3 will print some assertions to the kernel log, return an error
to the application that wanted to read the file and continue to
run.
- reiserfs will crash the machine.
- XFS I do not know.
Please hold you feets still until DRBD-0.8 is released. In DRBD-0.8 we
will support primary/primary, and with on of OCFS2, openGFS or GFS
you will be able to build such a setup.
-Philipp
--
: Dipl-Ing Philipp Reisner Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria http://www.linbit.com :