Wednesday, July 27, 2011

Thoughts on Database Replication - Slony-I

These days I'm dealing with database replication issues with PostgreSQL. My first approach is using Slony-I, to this moment I've grasped the following pros and cons:

Pros

  • Postgresql version agnostic

  • Cascading replication (any replica can be the source of any other replica)

  • Incremental replication

  • Any replica can take over the master role when needed.

  • Not SPF (Single Point of Failure)

  • Serves as a means for Postgresql Hot configuration and version upgrade


Cons

  • Asynchronous.

  • Does not replicate schema changes automatically.

  • It assumes that all nodes in the network are always available.

  • Hard to administrate and maintain.


I might be giving a small lecture on this topics but I'll require more time to share something worthwhile sharing. I need also to verify whether it is also OS / architecture agnostic.

I'm also interested in implementing a cluster supervised by some "Linux High Availability" mechanism such as HeartBeat, Pacemaker, Corosync, LVS ,  etc. There's much to implementing database replication and high availability that's why is so interesting.

Wednesday, July 20, 2011

Documenting everything, I mean everything


  • Regarding documentation, today I was given the advise to document everything, especially that information that is shared among team members, and changes to it. Trusting too much our's and other's memories might not be wise.

  • Even highly intelligent people sometimes make mistakes and even blunders, but that doesn't change my good regard towards them. What separates them apart from the rest, is that they acknowledge those mistakes modestly and take steps to prevent them from happening again in the future.

  • Having a good opinion of someone and sharing openly that opinion is one way to grow along with that person.

  • Reading books the old way, i.e. paper format at the library, turns out to be very effective. We're entertained with an awful lot of distractions whilst at the computer. I'm reading this way a selection of tales from Anton Chekhov and I like it very much.

  • The things we share with colleagues outside business settings are decisive in the kind of relations that are established inside those business settings.

Sunday, July 17, 2011

High Availability (failover) - Round-robin DNS

I'm coming back to this blog, but I'll be posting only short notes. I need to learn a lot these days, but there's no much time to document all that learning.

  • Round-robin DNS is a feature provided by implementations like BIND9 with which you can load-balance your services, provided that all the servers are in sync. Though many people argue that this mechanism is not intended for failover which is my main focus of attention.

  • The way it works is pretty straight forward:



  1. You define several records with the same name, but pointing to different IP addresses.

  2. The priority among those records gets permuted every now and then.

  3. Mixed with the proper specification of the TTL parameter you can distribute requests more or less equally.


The high availability issue is a very interesting one. This was my first approximation to that matter, and there are many more alternatives left to explore. One drawback of this option is that servers need to be in perfect sync and for the time being I'm using  an asynchronous solution for replication.