| Subject | Re: Remote Shadows (again...) |
|---|---|
| Author | m_theologos |
| Post date | 2006-10-04T06:38:13Z |
--- In Firebird-Architect@yahoogroups.com, "Leyne, Sean" <Sean@...>
wrote:
performance penalty appears only at writes, which in most cases, are
a small percent from the database activity. And, anyway, nobody is
enforced to use it. And again, this doesn't mean that the forced
writes feature must be dropped of because it hurts performance. (And
as I stated before I'm ready to benchmark this).
previous posts).
big OS vendors (MS and Linx powerhouses) they all go in this
direction.
of SANs are NOT in-sync (as the shadows are). So, then, is better to
use an internal, dedicated, replication trigger-based engine in which
the movement costs are much smaller. And, BTW, in SANs the database
performance will be faster? more reliable? Keep in mind that these
topologies copy/replicate the files in binary mode, as a common ones,
which is one of the most common causes of database corruption.
HTH,
m. th.
wrote:
>search
> M,
>
> > The problem:
> >
> > 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
> > on the group's webpage at Yahoo! using 'shadow' for fulldiscussions
> > about this topic. Anyway we can talk again if you want...)order
> >
> > Proposal:
> >
> > To relax a little bit the constrains imposed by the server in
> > to allow us to create a shadow remotely.be
>
> I do not support the notion of NFS attached shadows. They can only
> problematic:Over a link of 1Gbps the network is (quite) transparent. And the
>
> - database performance
>
performance penalty appears only at writes, which in most cases, are
a small percent from the database activity. And, anyway, nobody is
enforced to use it. And again, this doesn't mean that the forced
writes feature must be dropped of because it hurts performance. (And
as I stated before I'm ready to benchmark this).
> - shadow reliabilityThe Alex's experience is contrary. (Talk to him and/or see the
>
previous posts).
> - overall impact on the perception of the database should someoneWhy? You must know where you have the files. And if you look at the
> experience a problem using this approach.
>
big OS vendors (MS and Linx powerhouses) they all go in this
direction.
>as
> With the growing acceptance of SAN storage, (which is available for
> little as $5000 USD) the need for NFS/remote storage is quicklybecoming
> a thing of the past.$5000 USD? A lot of money for us. And the disaster recovery features
>
of SANs are NOT in-sync (as the shadows are). So, then, is better to
use an internal, dedicated, replication trigger-based engine in which
the movement costs are much smaller. And, BTW, in SANs the database
performance will be faster? more reliable? Keep in mind that these
topologies copy/replicate the files in binary mode, as a common ones,
which is one of the most common causes of database corruption.
HTH,
m. th.
>
> Sean
>