|
I do recognize this is not *perfect* I run the Rsync every 20 minutes, and
then I run myismchk on the slave system immediately afterwards. I run the
MyISMChk to only scan Tables that have changed since the last check. Not all
my tables change every 20 minutes. I will be timing operations and lowering
this Rsync down to approximately 12 minutes. This method works very
effectively for managing a 6 Gig Database that is changing approximately 400
megs of data a day.
Keep in mind, there are no *real time* replication methods available for
MySQL. Running with MySQL's building Replication commonly results (at least
with a 6 gig / 400 megs changing) in as much as 1 hour of data
inconsistency. The only way to get true real time is to use a shared storage
array.
Mike.
> 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.)
>
>
> -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
>
|
