On 8/5/10, Todd Denniston <Todd.Denniston at tsb.cranrdte.navy.mil> 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.