On 8/5/10, Todd Denniston <Todd.Denniston@xxxxxxxxxxxxxxxxxxxxx> wrote:
> You speak of transactions in a way that makes me think you are dealing with
> databases.
That's part of the application suite. Although we do suggest to
clients to have different servers for each particular use, some of
them are budget constraints and fortunately also have low loads. Both
due largely to the fact they are usually small operations as well. So
we end up having to setup servers which double/triple up as
web/email/application. We are trying to keep things separate in the
sense by using VMs for each purpose so that we can eventually migrate
them with minimum complications to individual machines when their
business grows to that level.
> If this is the case, then I suggest you take a few searches over to the drbd
> archives** and look for
> database issues, IIRC in some cases you are better off (speed and admin
> understanding/sanity)
> letting the database's built in replication handle the server to server
> database transactional sync
> than to trust a file system or even drbd to do it, because the db engine
> can/will make sure the
> backup db server ALSO has the data before reporting the transaction done.
> Not saying that having the DB on top of gluster or DRBD too would be bad,
> just suggesting that you
> may want to have the DB backed by something that fully understands the
> transactions.
Definitely running the DBMS' own transaction logging and replication
feature is part of the plan.
I know DRDB has the option to report a write as done only when both
copies are written so it's not an issue. However, I thought the slight
delay snapshot comment was about using ZFS snapshot send/receive
replication? I don't really know the details on that so took your word
for it that it involves some kind of perceivable delay likely similar
to the several seconds long timing of delayed allocation. That was
what I was responding to as being not acceptable, sorry if I caused
any confusion.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
