|
"Alexander N. Spitzer" <aspitzer@xxxxxxxxx> said:
> how often are you running rsync? since this is not realtime replication,
> you run the risk of losing information if the master dies before the rsync
> has run (and new data has been added since the last rsync.)
FWIW
I have one client where we do this. At this moment ( I just checked) their
database is 279 megs. An rsync from one box to another across a local 100mbit
connections takes 7-10 seconds if we run it at 15 minute intervals. If we run
it at 5 minute intervals it takes < 3 seconds. If we run it too often, we get
an error of "unexpected EOF in read_timeout".
I don't know what causes that error, and they are very happy with the current
situation, so I haven't spent any time to find out why. I assume it has
something to do with write caching or filesystem syncing, but that's just a
wild guess with nothing to back it up. For all I know, it could be ssh related.
We also do an rsync of their http content and httpd logs, which total
approximately 30 gigs. We run this sync hourly, and it takes about 20 minutes.
-=dwh=-
>
-alex
>
> -----------------------------------------------------------------
> Alexander N. Spitzer Email: aspitzer@xxxxxxxxx
> Unix Systems Engineer Phone: 617.349.9361
> http://www.3plex.com
eFax : 509.752.4680
>
> On Fri, 14 Sep 2001, Michael McConnell wrote:
>
> > I've just completed the Rsync deployment method, this works very well. I
> > find this method vastly superiors to both other methods we discussed.
> > Using Rsync allows me to only use 2 HOSTS and I can still provide 100%
> > uptime. In the other method I need 3 systems to provide 100% uptime.
> >
> > In addition the Rsync method is far easier to maintain and setup.
> >
> > Thoughts?
> >
> > Mike
> >
> >
> > ----- Original Message -----
> > From: "Paul Baker" <pbaker@xxxxxxxxxxxxxxx>
> > To: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
> > Sent: Friday, September 14, 2001 1:48 PM
> > Subject: Re: MySQL Replication
> >
> >
> > > Michael McConnell wrote:
> > > > Paul you are correct. My apologizes.
> > >
> > > You don't have to apologize. Trying to explain it to you only helps me
> > > understand it better as well. :-)
> > >
> > > >
> > > > I've just done this experiment.
> > > >
> > > > A(master) -> B(slave)
> > > > B(master -> C(slave)
> > > >
> > > > A Died.
> > > > Turn of C's Database, tar it up, replicated the Data to A
> > > > Activate A as Slave to C
> > > >
> > > > No data loss, and 0 downtime.
> > > >
> > >
> > > Glad to have helped you anyway I can!!!
> > > --
> > > =======================================================================
> > > Paul J. Baker Internet Systems Developer
> > > pbaker@xxxxxxxxxxxxxxx Where2GetIt.com
> > > phone 847-498-0111x234
> > > fax 847-480-7422
> > > =======================================================================
> > >
> > >
> > >
> > > _______________________________________________
> > > LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> > > Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> > > or go to http://www.in-addr.de/mailman/listinfo/lvs-users
> > >
> >
> >
> > _______________________________________________
> > LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> > Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> > or go to http://www.in-addr.de/mailman/listinfo/lvs-users
> >
>
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
--
________________________________________________________________
http://www.OpenRecording.com For musicians by musicians.
Now with free Web-Based email too!
|
