Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi, On Wed, Sep 7, 2011 at 10:28 PM, Nick Khamis <symack at gmail.com> wrote: > Hello Everyone, > > We are looking to setup write intesive services using database > technologies. Doing some research I yielded > the attached document. Is there a issue in terms of performance using > DRBD on an active active, and say > mysql database? That being said, what is the best combination for > clustering using DRBD: > > OCFS2 active active > EXT3 active passive The second one. > > On top of HA, load balancing is also important to us. The document also detailed MySQL Cluster using the ndb engine. There are some benefits for using such a solution, but also downsides, therefore it is best to evaluate all of your requirements and see which fits best. On the MySQL Cluster with ndb approach, you have to assess what will be the database/s size/s, what would be an estimated growth per week, month, year, and plan your hardware requirements accordingly, as well as plan for expansion, as ndb is an in-memory database, which on MySQL Cluster scales to multiple nodes by partitioning the database and having a primary copy of a partition on a node, and one or more (minimum is one) backup copy of the same partition on another node (all stored in RAM). As more nodes are added to the MySQL Cluster, the partitions are split further and replicated onto new nodes as well, it allows linear scaling iirc. Every node maintains a transaction log on disk, therefore allowing recovery of a node based on this log. However, a node failure does not lead to service interruption, as there always is at least one other node maintaining a backup copy of the partition of the failed node in memory. When failure is detected, the node keeping the backup copy makes his copy primary and sets a new node to keep a backup copy. Also, all transactions are performed atomically via a two-phase commit protocol. MySQL Cluster usually does not imply the usage of another clustering technology on the same nodes, and given the high memory consumption, it's usually not the case to mix things where it isn't needed. One possible scenario would be to have all writes done on the MySQL Cluster, and from it have N frontends set up as Replication Slaves for Read requests. Load balancing writes can be done by having a frontend issue requests to each Data Node, but it's recommended that requests are sent to the DC (IIRC) and it will (based on whom has the writeable copy of a partition) send the request to the Data Node storing it, then that Node will send the reply to the frontend. There are multiple scenarios possible, but they usually involve having writes performed on the MySQL Cluster (it supports simultaneous access for read/write operations on every node via the two-phase commit protocol) and having read requests either on the Cluster or on Replication Slaves with the second option being the recommended one. MySQL Cluster holds all the databases in memory, so it's very fast, has self healing capabilities, built-in high availability, it can also use all of the CPU cores in a system and it relies on network transport for communication between nodes, thus one can upgrade the interconnects to Infiniband or some other solution for maximum performance. In terms of planning for MySQL Cluster, the following links will give some insight: http://www.severalnines.com/sizer/ http://www.fromdual.ch/mysql-cluster-memory-sizing The only use case for DRBD in a MySQL Cluster would be to also replicate the logs that it flushes to disk. In the event of a node failure, the cluster is still fine, as explained above, but restoring a node might take some time (get the log from the failed node, copy it to a new node, load it into RAM, join the node to the cluster, the node updates it's data to match the cluster state || fix the node, restore or not the logs, load them into RAM, etc.). By having the logs on a DRBD partition, and replicating it to another server, the data is still available, if you have a spare server, then it's just a matter of promoting the DRBD partition to Primary, mounting it, then export it via NFS or whatever, mount it on the spare server, start loading the logs into RAM, join the node to the Cluster. It reduces MTTR. Hope it sheds some light onto the picture. Regards, Dan > > Thanks in Advnace, > > Nick > > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user > > -- Dan Frincu CCNA, RHCE