| Subject | Re: [Firebird-Architect] Remote Shadows (again...) |
|---|---|
| Author | Alex Peshkov |
| Post date | 2006-10-04T08:07:07Z |
m_theologos:
at some path. It's not very interesting, how is it done in engine - code
is trivial, and it's very easy to let it create shadows for any other
file sharing protocol. The interesting question is why this was done
only for NFS.
Writing pages to database file is not trivial process - in order to be
able to recover database after system failure we must ensure correct
order of pages written to the disk, this is known as 'safe write order'.
OS often does it's best to break safe write order - for example, it
optimizes order of pages to be written to the disk to minimize movement
of HDD heads. We set special flags when opening databases file to avoid
such optimizations. Not necessary to mention, that safe write order
should be kept for shadows too. And here is an answer why NFS is a
special case - it can keep safe write order of pages in database shadow.
I'm not very familiar with windows file sharing. If one gives us a
reference (to MSDN, for example), which describes how to guarantee safe
write order for windows-based network, I see no problems enabling
shadowing across MS network. Without guarantees of keeping safe write
order, shadowing may become very dangerous feature - you can easily get
a heap of useless bytes instead of a normal database in your shadow.
What about performance problems on network shadows. They are not too
big. As soon as you take into account that all reads are done from
primary database file, and only writes are repeated for shadows, you
will notice that there are no big problems here. Next, if you use
dedicated 1GBit link for shadow, you have approx 100MBytes/sec
throughput, which is exactly what good hard disk has (certainly I don't
speak about high-end devices - 10GBit network should be used in high-end
case).
Concerning reliability - from my own experience NFS does it's work very
well. One of our customers had a 'wonderful' UPS which used to turn off
output voltage at random moments. But they never had broken mirror,
though in some cases they had broken primary file!
Summarizing - if we can guarantee safe write order for some network
protocol, enabling shadows over it is very good feature. Though for MS
products some crash-tests should be also fine - I do not trust M$ products.
Alex.
> The problem:/// skipped
>
> When someone tries to create a shadow on a remote drive the server
> refuses to create it.
>
> Advantages:
> - Database mirroring (more details on previous threads. Do a search
> on the group's webpage at Yahoo! using 'shadow' for full discussions
> about this topic. Anyway we can talk again if you want...)
>
> Proposal:
>
> To relax a little bit the constrains imposed by the server in order
> to allow us to create a shadow remotely.
>
> How managed Alex (Peshkov) to create shadows on NFS points... (onNFS is a special case when engine checks for ability to create DB shadow
> Windows not even with mapped drives I cannot trick the engine...)
>
at some path. It's not very interesting, how is it done in engine - code
is trivial, and it's very easy to let it create shadows for any other
file sharing protocol. The interesting question is why this was done
only for NFS.
Writing pages to database file is not trivial process - in order to be
able to recover database after system failure we must ensure correct
order of pages written to the disk, this is known as 'safe write order'.
OS often does it's best to break safe write order - for example, it
optimizes order of pages to be written to the disk to minimize movement
of HDD heads. We set special flags when opening databases file to avoid
such optimizations. Not necessary to mention, that safe write order
should be kept for shadows too. And here is an answer why NFS is a
special case - it can keep safe write order of pages in database shadow.
I'm not very familiar with windows file sharing. If one gives us a
reference (to MSDN, for example), which describes how to guarantee safe
write order for windows-based network, I see no problems enabling
shadowing across MS network. Without guarantees of keeping safe write
order, shadowing may become very dangerous feature - you can easily get
a heap of useless bytes instead of a normal database in your shadow.
What about performance problems on network shadows. They are not too
big. As soon as you take into account that all reads are done from
primary database file, and only writes are repeated for shadows, you
will notice that there are no big problems here. Next, if you use
dedicated 1GBit link for shadow, you have approx 100MBytes/sec
throughput, which is exactly what good hard disk has (certainly I don't
speak about high-end devices - 10GBit network should be used in high-end
case).
Concerning reliability - from my own experience NFS does it's work very
well. One of our customers had a 'wonderful' UPS which used to turn off
output voltage at random moments. But they never had broken mirror,
though in some cases they had broken primary file!
Summarizing - if we can guarantee safe write order for some network
protocol, enabling shadows over it is very good feature. Though for MS
products some crash-tests should be also fine - I do not trust M$ products.
Alex.