Andreas Kostyrka wrote:
> takes over. The thing you worry about is if all data has made it to the
> replication servers, not if some data might get lost in the hardware
> cache of a controller. (Actually, talk to your local computer forensics
> guru, there are a number of way to keep the current to electronics while
> moving them.)
>
But it doesn't, unless you use a synchronous rep at block level - which
is why we have SRDF.
Log-based reps are async and will lose committed transactions. Even if
you failed over, its
still extra-ordinarily useful to be able to see what the primary tried
to do - its the only place
the e-comm transactions are stored, and the customer will still expect
delivery.
I'm well aware that there are battery-backed caches that can be detached
from controllers
and moved. But you'd better make darn sure you move all the drives and
plug them in in
exactly the right order and make sure they all spin up OK with the
replaced cache, because
its expecting them to be exactly as they were last time they were on the
bus.
> 3.) a controller cache is an issue if you have a filesystem in your data
> path or not. If you do raw io, and the stupid hardware do cache writes,
> well it's about as stupid as it would be if it would have cached
> filesystem writes.
>
Only if the OS doesn't know how to tell the cache to flush. SATA and
SAS both have that facility.
But the semantics of *sync don't seem to be defined to require it being
exercised, at least as far
as many operating systems implement it.
You would think hard drives could have enough capacitor store to dump
cache to flash or the
drive - if only to a special dump zone near where the heads park. They
are spinning already
after all.
On small systems in SMEs its inevitable that large drives will be shared
with filesystem use, even
if the database files are on their own slice. If you can allow the drive
to run with writeback cache
turned on, then the users will be a lot happier, even if dbms commits
force *all* that cache to
flush to the platters.