469,081 Members | 1,861 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,081 developers. It's quick & easy.

WHY Replication???

Hi all...
We system analysts need to trust on our database software. Once they
crash, all of hard work will be lost.

So, people says replication is a good way to keep your data safe.
Let me present you my point.

I am using a RedHat 9.0/Mysql with a Raid 1(Mirror) file system. In
case of a file error, the software raid 1 will handle this problem and
replication will not add any good.
Another crash could be a MySql bug, and in this case the slave Mysql
will crash too.
So, why should i replicate???

Remember it's a case of safe data, not fast response.

I am just logging (bin-log) the changes made on database data. In
case of crash, i will rebuild the database using this log.
By the way, how can i rebuild the data using the log? What is the
command?

I think the log is recorded before the query is runned. This way, the
log is complete safe. Am i right?

One more qustion...

Since the log will keep increasing, there is no way to check the
logged querys runned all right and delete then from log? Does Mysql do
this automatic?
Thanks!
Jul 20 '05 #1
2 1792
In article <79**************************@posting.google.com >,
jo*********@yahoo.com (JoeAley2003) wrote:

So, people says replication is a good way to keep your data safe.
Well, I don't know anyone who says that, and I don't really agree.
Replication is more of a way to ensure high availability than it is
a way to "keep data safe."
Let me present you my point.

I am using a RedHat 9.0/Mysql with a Raid 1(Mirror) file system. In
case of a file error, the software raid 1 will handle this problem and
replication will not add any good.
True, but what if the machine's power supply fizzles out? What if
the CPU fan dies and the systems shuts down because it overheats?
Your data would be "safe," but it would also be inaccessible until
the machine is repaired.

If the databases were replicated on another machine, you could
switch to using that one and keep right on running.
Remember it's a case of safe data, not fast response.


Well, again, replication is more about high availability than it is
about data safety.

--
Jul 20 '05 #2
John Doherty wrote:
So, people says replication is a good way to keep your data safe.


Well, I don't know anyone who says that, and I don't really agree.
Replication is more of a way to ensure high availability than it is
a way to "keep data safe."


I agree, and in general replication is used for redundancy.

One of the things that redundancy can buy for you is high availability
in case of scheduled or unscheduled downtime for a server. So in both
cases of catastrophic failure and of planned maintenance, upgrade, etc.,
there is benefit from a duplicate database being available.

In cases of catastrophe, replication gives you a live instance of a
database that is in sync with the one that crashed. It's like having a
backup in progress continuously, and with virtually no time needed to
restore it in case of crash.

Redundancy can also be used for load-balancing. If you have multiple
databases in sync with one another, and a need for a large volume of
high-performance query response time, you can use various software or
hardware methods to redirect requests to one server or the other. But
the person with the question said that fast response time was not the
highest priority in this case.

Regards,
Bill K.
Jul 20 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Cherrish Vaidiyan | last post: by
reply views Thread by Cherrish Vaidiyan | last post: by
3 posts views Thread by steve | last post: by
1 post views Thread by Craig HB | last post: by
3 posts views Thread by dlesandrini | last post: by
9 posts views Thread by David W. Fenton | last post: by
3 posts views Thread by Gert van der Kooij | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.