After reading at a lot of places for the the single repeatative question, “What engine shall I choose – MyISAM or Innodb?”, this is what I’ve got. Following are points…

The post Choosing between MyISAM and INNODB – MySQL Storage Engines first appeared on Change Is Inevitable.

The perl script is mainly created to avoid manual Mysql Server Maintenance. The script uses Perl module DBI. You need to provide access credentials and database name(optional). Regarding Analyse, Optimize…

The post Perl Script for Analyze – Optimize – Repair Mysql Databases first appeared on Change Is Inevitable.

As part of our partnership with Dolphin Interconnect Solutions, we are presenting two webinars on DRBD for Dolphin Express on Nov. 5 (European business hours) and Nov. 12 (American business hours).

Both DRBD and Dolphin Express already being a fixture in the MySQL universe, this webinar should be particularly interesting to those of you who want to minimize database write latency while maintaining fully redundant and transaction-safe high availability. However, it’s also a must see for virtualization and mail service DRBD users, who also typically have a need for low latency.

This …

A public draft version of the all-new DRBD Users’ Guide has just been released. Feedback is more than welcome.

You may want to read the announcement as well.

DRBD 8.2.3 was released today. Even though just a micro release in terms of version numbering, it comes with a couple of very handy brand new features: on-line device verification, and tunable processor affinity.
(more…)

I’ve been asked by a number of people on how to do an upgrade from DRBD version 0.7 to DRBD 8. This upgrade does necessitate some minimal service down time, but it’s really not rocket science. And no, it does not force you to sync all of your data all over again.

Here’s my quick write-up.

An initial word of caution

Do not, I repeat do not attempt your upgrade unless you have at least read this blog entry to the finish.

Getting ready

First, you need to make sure that you have both your DRBD 8 userland binaries and kernel module ready to install. For our support customers, this means that you simply download two RPMs (or .debs) from our support web site. Make sure you have the right packages; you want those that match your system architecture and (for the kernel module) also your running kernel. Also, make sure you get …

Split brain, with DRBD, is much less of a disaster than in conventional cluster setups employing shared storage. But, you ask, how can I protect my DRBD cluster against split brain in the first place? Here’s how.

Let’s briefly reiterate what split brain, in the DRBD sense, really means. DRBD split brain occurs when your nodes have lost their replication link due to network failure, and you make both nodes Primary after that.

When just the replication link dies, Heartbeat as the cluster manager will still be able to “see” the peer node via an alternate communication path (which you hopefully have configured, see this post). Thus, there is nothing that would keep Heartbeat from migrating resources to that DRBD-wise disconnected node if it so decides or is so instructed. That would cause precisely the DRBD split …

DRBD 8.2.0, released today, includes a much requested new feature, embodied in the new data-integrity-alg configuration option: DRBD protocol level data integrity checksums.

A few months ago, some users alerted us to DRBD replication issues where DRBD supposedly “ate their data”, i.e. corrupted replicated data in transit. Eventually we traced those problems not to DRBD errors, but in fact to network drivers messing up TCP checksums or segmentation. Typically this was related to using either TCP segmentation offloading (TSO) or TCP checksum offloading. However, at the time DRBD had no way of detecting these errors — you would only find out if you switched over to your Secondary, only to find your data not having been replicated properly.

With DRBD 8.2.0, you can check the integrity of replicated data in transit. To that end, …

These days, we seem to be getting a lot of inquiries from new or would-be DRBD adopters, especially MySQL and PostgreSQL DBAs wanting to add high availability to their master database servers. And these, unsurprisingly, turn out to be two of their most popular questions:

How will using DRBD affect my write performance?

… and …

What are DRBD’s most important tunables with regard to write performance?

Let’s take a look at both of these issues. Ready? Let’s go.

Basically, there’s usually one important potential bottleneck in any DRBD “Protocol C” (synchronous replication) setup, and it’s not the network connection. With ubiquitous Gigabit Ethernet links available to be dedicated for DRBD replication, network latency and throughput become negligable variables. The …

As I’m sure you’re aware, DRBD disallows access (any access, including read-only) to a DRBD device in Secondary mode. This always raises questions like the one I’ve taken the liberty to quote here. It came up in a MySQL webinar on replication and HA:

Because of the asynchronous nature of [MySQL] replication we end up with a dilemma when looking at using slaves as read nodes in that the only time we go to the database for information is to build a local cache file, and that local cache file is ONLY removed when information related to that cache file changes, it is NOT based on time. If we had a synchronous method of replication we would then know the cache files were always getting the right information, but because of the asynchronous nature …