Skip to content
ruismoura edited this page Sep 28, 2015 · 12 revisions

What is this?

This project was done during my 7 week internship at Multicert.

The aim of the project is to make a client transparent SQL database system capable of losing at least one machine with minimal or zero downtime that also uses the redundant machines to improve performance. These objectives are limited to the local network, meaning that making the Internet access redundant is beyond the scope of the project.

Full disclosure: I have very little experience with PostgreSQL and databases in general so don't be surprised if you find a few wrong things.

I tried to be very thorough and careful with both the research and the documentation, so hopefully you won't even notice too much :)

Is it for me?

If you have a database that you need to keep on-line all the time, you should be looking at solutions like this one. The architecture used only improves read performance, if your database load is mostly writes you should look for a different solution. This setup is also very focused on avoiding data loss because of concurrent accesses.

Keep in mind that depending on what your database needs are, you might be better off using different topologies or even different database management systems. It can be very hard to migrate your data later on when you find out.

You should especially look at the differences between SQL and No-SQL databases.

Why use PostgreSQL?

There are quite a few SQL database management systems but PostgreSQL stands out as one of the few free ones and for being a community driven open-source project with regular updates. There are also many projects built to add functionality to PostgreSQL (like PgPool II, which is used here).

What isn't in the scope of this guide:

  • How to secure the database from unauthorized access
  • How to get the best performance out of this setup
  • How to make your network access redundant