Hi,
Couple options were mentioned here - here's some comments:
*block based replication (DRBD) (+HA and/or PACEMAKER and/or Wackamole)*
While this is an interesting solution, you will still have some major (10+
seconds) downtime as you will not be able to use the shared storage with 2
parallels MYSQL process (on different systems). The block device will be
replicated, but even with primary/primary mode on DRBD (with cluster-aware
filesystem like OCFS2 or GFS), a failure will require 'detection' + 'ip
migration' + 'service start (& file system lock)'.
DRBD is good for static data (such as webfiles), but database comes with
their own replications solution.
*
*
*File based replication (GlusterFS & similar stuff) :*
Whatever you hear about file base replication, it is always a bad idea for
database.
*
*
*
*
*MYSQL Replication*
This is the easiest solution & one that can be setup so no downtime is
experienced:
- setup 2 MYSQL servers
- configure (at the very least) the following setting:
server_id (must be different)
auto_increment_increment (must be the same, required for dual master
setup with potentially overlapping auto-increment key)
auto_increment_offset (must be different, required for dual master
setup)
as mush bin_log as you can
enable the log_slave_update setting ; useful in case of full rebuild
-get maatkit (most important to setup would be the db/table checksum
functions)
-setup your mysqldump with master-data=2 (read about it, can/will cause
locking!)
read through :
http://dev.mysql.com/doc/refman/5.0/en/replication-features.html
maatkit: http://www.maatkit.org/doc/
This will bring you to a point where you have 2 MYSQL servers that can be
queried (read and write) at the same time. Over that, I'd suggest installing
a local mysql-proxy server on each of your application server with a lua
file that will allows for dual master. MySQL-Proxy is now included in almost
all distribution repository (or available through its sources files) ...
Using this kind of setup, you won't even have to modify your application,
play with ips or sell your souls ;-)
I'm starting a night of operations in a couple minutes, haven't had my
coffee yet... send me any questions you might have about such a setup. Been
deploying that kind of redundant setups for years. Bth, it is also a good
idea to think about a dedicated mysql read-only slave for backup in such a
case.
P.
<http://www.maatkit.org/doc/>
--
Pascal Charest, skype: pascal.charest
Cutting-edge technology consultant @ Les Laboratoires Phoenix
http://www.labsphoenix.com
On Tue, Jan 18, 2011 at 12:53 PM, Gord Fisch Arboreta <[email protected]>wrote:
> Another method, though maybe we're going crazy here, is to use DRBD and
> heartbeat.
> DRBD will write your mysql changes to two machines, and heartbeat will
> manage the IP and mysql.
>
> Gord
>
> --
> Arboreta Internet Services
> Gord Fisch
> http://www.arboreta.ca
> skype: gord.fisch
> land: 514-481-8524
> cell: 514-969-9928
>
>
>
>
> On 01/18/2011 11:41 AM, David Filion wrote:
>
>> On 1/18/2011 9:47 AM, Stephane Bakhos wrote:
>>
>>> Set the timeout to near 0 and have mysql_connect retry on the other on
>>> failure.
>>> OR
>>> Set a haproxy in front of the MySQL servers to connect to whichever one
>>> responds.
>>>
>>>
>>>
>> The apps in question are vbulletin and wordpress sites so I can only
>> specify one target server. That's why I was thinking master/slave. Point
>> them to the floating ip and if the server holding the ip crashes move the ip
>> to the other server. The problem as I mentioned is the mysql clean up
>> afterwords is messy and highly manual.
>>
>> I guess I could always go master/master and still move the mysql ip
>> address from one server to the other.
>>
>> This is for a half dozen _low_ traffic sites so I don't want to go crazy,
>> I just want redundancy.
>>
>> David
>> _______________________________________________
>> mlug mailing list
>> [email protected]
>> https://listes.koumbit.net/cgi-bin/mailman/listinfo/mlug-listserv.mlug.ca
>>
>>
> _______________________________________________
> mlug mailing list
> [email protected]
> https://listes.koumbit.net/cgi-bin/mailman/listinfo/mlug-listserv.mlug.ca
>
_______________________________________________
mlug mailing list
[email protected]
https://listes.koumbit.net/cgi-bin/mailman/listinfo/mlug-listserv.mlug.ca
