Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Luciano Miguel Ferreira Rocha wrote: > On Sat, Jul 29, 2006 at 09:27:08PM +0200, Ondrej Jombik wrote: > >> What is particulary not clear for me is, if secondary/slave partition >> can be mounted read-only (ro) or it is not possible to mount it at all >> (without switching to master mode)? >> > > You'll have data changing underneath the kernel without it's knowing. > Problems are bound to arise. > What if you unmount the secondary, flush the OS cache (using /proc/sys/vm/drop_caches) and remount regularly? I can't see why this wouldn't work for specific use-cases (such as processing Postgres' WAL (write ahead log)). I've asked this before, and heard nothing back, I'd be very interested on any feedback anyone can offer. Here's my last question which explains my plan in detail. I'd like to emphasise that DRBD would ONLY have the WAL on it (which are sequential files, with new data only getting appended (on the primary)). Can anyone suggest any reason this wouldn't work? I should be running tests on this soon. Craig P.S. Could LVM snapshots get around the problem if my suggestion doesn't? -------- I'm wondering if the new kernel option "drop_caches" would allow read only access to the secondary? http://linux.inet.hr/proc_sys_vm_drop_caches.html The reason I want this is for the following scenario * Primary machine has a small DRDB partition with the Postgres "write ahead log" (perhaps stored in a battery backed RAM disk for performance) * Secondary machine has a copy of the PG database (NOT on the DRBD partition), and, as long as it can READ the write ahead log mirror (DRBD or Raid1), it can keep a hot remote ACID compliant backup of the postgres database. Something like this on the secondary while true do mount -o ro /mnt/pg_wal process new WAL entries (this is a read only op, on what is basically a sequential file that just gets added to by the primary) umount /mnt/pg_wal echo 3 > /proc/sys/vm/drop_caches # see below sleep 2 done Here's the details from the above link, about the new proc option. Can anyone give me any feedback on whether this is a viable option? ------------------------ drop_caches Writing to this will cause the kernel to drop clean caches, dentries and inodes from memory, causing that memory to become free. To free pagecache: * echo 1 > /proc/sys/vm/drop_caches To free dentries and inodes: * echo 2 > /proc/sys/vm/drop_caches To free pagecache, dentries and inodes: * echo 3 > /proc/sys/vm/drop_caches As this is a non-destructive operation and dirty objects are not freeable, the user should run "sync" first.