Example haresources from $charity

server-nfs-01 charitynfs IPaddr::10.0.1.90/27/eth0 drbddisk::nfs Filesystem::/dev/drbd1::/srv/nfs::xfs

Example ha.cf from $charity

# debug output
debugfile /var/log/ha-debug.log
# all other logs
logfile /var/log/ha-log.log
logfacility local0
keepalive 1
deadtime 10
warntime 3
initdead 20
bcast eth0
auto_failback off
# STONITH
#stonith_host * external/ssh 10.0.1.90 root nottherootpassword
node server-nfs-01
node server-nfs-02

Example DRBD conf from $charity

global {
     usage-count no;
}
common {
     syncer {
        rate 100M;
    }
}
resource nfs {
    protocol C;
    startup {
       degr-wfc-timeout 120; # 2 minutes.
   }
   disk {
      # on-io-error detach;
   }
   net {
      cram-hmac-alg sha1;
      shared-secret "removed";
   }
   on server-nfs-01 {
      device /dev/drbd1;
      disk /dev/mapper/ubuntu-SrvNfs;
      address 10.0.1.91:7788;
      meta-disk /dev/mapper/ubuntu-drbd[0];
   }
   on server-nfs-02
      device /dev/drbd1;
      disk /dev/mapper/ubuntu-SrvNfs;
      address 10.0.1.92:7788;
      meta-disk /dev/mapper/ubuntu-drbd[0];
   }
}

MySQL Master-master replication notes

I seem to have to keep looking up notes whenever I need to set up a multi-master MySQL replication ring. I thought I'd put it all down in one place that I can find easily - on my own blog.

This is not a howto, it's just notes, I can't guarantee these are accurate or without faults.

1. Install MySQL server on Server A and B

apt-get install mysql-server

2. On Server A, grant replication privileges to a replication user

grant replication slave on *.* to 'replication'@'server_b' identified by 'slavepw';

3. MySQL config on Server A:

server-id               = 1
log_bin                 = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M
binlog_do_db             = testdb
binlog_ignore_db        =mysql
relay-log=mysqld-relay-bin

Restart Server A MySQL

4) Edit Server B config:

server-id               = 2
log_bin                 = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M
binlog_do_db            = testdb
binlog_ignore_db        =mysql
relay-log=mysqld-relay-bin
master-host = server_a
master-user = replication
master-password = slavepw
master-port = 3306

5) Restart MySQL on Server B, then:

start slave;
show slave status\G;

These should be both Yes, also check that the Master Host, binlog and positions all match (by comparing with 'show master status;' on Server A

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

At this point we've a master->slave relationship. It's time to make Server B a master of Server A as well.

6. Set the replication privileges on Server B to become a master of Server A

grant replication slave on *.* to 'replication'@'server_a' identified by 'slavepw';

7. On Server B, add the master info to my.cnf so it knows it's a slave of Server B

master-host = server_b
master-user = replication
master-password = slavepw
master-port = 3306

8. Restart Server B and then Server A

(not sure if it matters what order really)

9. On Server A:

start slave;
show slave status\G;

These should be both Yes, also check that the Master Host, binlog and positions all match (by comparing with 'show master status;' on Server B

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

10. start slave on Server B

(I guess, or was it already started when MySQL restarted? It should do it automatically, try to remember from 2008 what we did here to make sure it does)

Unless there's errors for either node connecting to each other, should be ok to create the database testdb on Primary or Secondary (the creation will replicate to the other node), and start creating tables/data on either node.

Playing with CouchDB

Experimenting with a bunch of VMs and CouchDB for
scalable, replicated filesystem purposes.

I like the way it stores any object as a 'document' in its database, doesn't depend on another
database backend like MogileFS seems to.

I'm slightly wary of the fact that the replication isn't built as part of the daemon's
responsibility automatically on the fly, by way of which you could control via the config ini
file. Instead replication is a manually executed process either via the web interface or via