Nikola Savic wrote:
Gordan Bobic wrote:
Something else just occurs to me - you mentioned MySQL. You do realize
that the performance of it will be attrocious on a shared cluster file
system (ANY shared cluster file system), right? Unless you only intend
to run mysqld on a single node at a time (in which case there's no
point in putting it on a cluster file system).
MySQL Master and Slave(s) will run on single node. No two MySQL
instances will run on same set of data. Shared storage for MySQL data
should enable easier movement of MySQL instance between nodes. Eg. when
MySQL master needs to be moved from one node to other, I assume it would
be easier with DRBD, because I would "only" need to stop MySQL on one
node and start it on other configured to use same set of data.
There is a better way to do that. Run DRBD in active-passive mode, and
grab the fail-over scripts from heartbeat. Then set up a dependency in
cluster.conf that will handle a combined service of DRBD disk (handling
active/passive switch), file system (mounting the fs once the DRBD
becomes active locally, and mysql. You define them as dependant on each
other in cluster.conf by suitable nesting.
Additionally, floating IP address assigned to MySQL master would need to
be re-assigned to new node.
You can make that IP a part of the dependency stack mentioned above.
Slaves would also need to be restarted to
connect to new master. Even without floating IP used only my MySQL
Master, slaves and web application can easily be reconfigured to use new
IP. Do you see problem in this kind of setup?
If the IP fails over and the FS is consistent you don't need to change
any configs - MySQL slaves will re-try connecting until they succeed.
Just make sure your bin-logs are on the same mount as the rest of MySQL,
since they have to fail over with the rest of the DB.
Gordan
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
