PostgreSQL Replication II

Some findings around replication following an earlier blog post.

I have a simple streaming replication setup with 1 primary and 1 standby DB server. My reference DB is about 42GB in size.

  • A full vacuum will break the replication. Remember, PostgresSQL is recreating every table in the full mode. This wont fit through any default sized xlogs.
    A regular vacuum works fine though.
  • In a complete disaster scenario where both primary and standby are corrupted I have to rely on the nightly pg_dump.
    The import on the primary DB server (AWS m2.4xl instance) takes about 3 hours to restore with the default parameters.
    We can significantly speed it up by utilizing more than 1 default CPU for the data and index creation using the j parameter. Constraints cannot be created in parallel though.
    sudo -u postgres pg_restore -j 8 -v -d dbname dumpfilename
    This way I could reducte the restore time to 70 minutes.
    I still have to get the standby in sync with pg_basebackup, takes another 60 minutes. This time I could reduce to 30 minutes by tar and copying the complete DB files over to the standby.
    (But pg_basebackup works while the primary server is in use, provided you have enough xlogs to cover the until you want to link the standby)

PostgreSQL Replication Express Setup

The system I work on we deploy almost solely on the Amazon AWS platform. Even I try to design the architecture in a way not to be locked-in too much into Amazon, I make use of the Amazon tools and products as much as possible (EC2, VPC, S3, SNS). PostgreSQL is our reference DB and the only DB product in production environments, still we run dedicated instances with PostgreSQL. I am quite delighted about AWS recent offering staring RDS with PostgreSQL. While is is still in BETA and I did not started yet with a conclusive test and migration plan, I need to maintain our existing instances.

There are plenty of books and tutorials about setting up PostgreSQL replication with on-board tools, without going into the details I share the express setup in this tutorial based on Streaming Replication which is part of PostgreSQL since version 9.0. I highly recommend to review the parameters and settings from the below tutorial as your project might have different requirements.

References

Tutorial

Remarks

  • The tutorial is based on PostgreSQL 9.2 running on Ubuntu Server
  • Paths and settings are all the PostgreSQL defaults.
  • This is async setup, the master will not wait for feedback from the salve and continue to work even the slave is not available

Prerequisite

  • 2 Server running the same PostgreSQL version (9.0+)
  • Backup your data or use a sandbox environment.
  • In the tutorial I refer to
    MASTER (ip: 0.0.0.1) and
    SLAVE (ip: 0.0.0.2)

Configuration

Master

  • Create a replicator user
    sudo -u postgres psql -c "CREATE USER replicator REPLICATION LOGIN ENCRYPTED PASSWORD 'mypassword';"
    
  • Add the slave ip to /etc/postgresql/9.2/main/pg_hba.conf
    host    replication     all      0.0.0.2/32         trust
    
  • Modify parameters in /etc/postgresql/9.2/main/postgresql.conf
    wal_level = hot_standby
    max_wal_senders = 3
    checkpoint_segments = 3
    wal_keep_segments = 3
    

    Review these parameters and set them up according to your requirements

  • Start the PostgreSQL instance
    service postgresql start
    

Slave

  • Modify parameters in /etc/postgresql/9.2/main/postgresql.conf
    wal_level = hot_standby
    max_wal_senders = 3
    checkpoint_segments = 3
    wal_keep_segments = 3
    hot_standby = on
    
  • Stop the PostgreSQL instance
    service postgresql stop
    
  • Clean up the old data directory
    sudo -u postgres rm -rf /var/lib/postgresql/9.2/main
    
  • Copy the database from the master with pg_basebackup
    sudo -u postgres pg_basebackup -h 0.0.0.1 -D /var/lib/postgresql/9.2/main -U replicator -v -P -x
    

    You can see the backup progress and it should result in something likes

    root@:/var/lib/postgresql/9.2/main# transaction log start point: 41/7D000020
    31524952/31524952 kB (100%), 2/2 tablespaces (/var/lib/postgresql/9.2/main/PG_9.)
    transaction log end point: 41/7D0002A8
    pg_basebackup: base backup completed
    
  • Create a recovery configuration file /var/lib/postgresql/9.2/main/recovery.conf
    standby_mode = 'on'
    primary_conninfo = 'host=0.0.0.1 port=5432 user=replicator password=mypassword sslmode=require'
    trigger_file = '/tmp/postgresql.trigger'
    
  • Start the PostgreSQL instance
    service postgresql start
    

    Check the pglogs.

Test the replication

  • Open any table with pgadmin on the master and apply a change, it should be reflected in the slave within short time.
  • Try to change data on the slave, it will fail due to the hot-standby mode

Monitor the replication

  • The master instance will not alert you when the replication is down. You can check by yourself or create a little cronjob to do it for you with this sql statement.
    sudo -u postgres psql -x -c "select * from pg_stat_replication;"
    

    You get the status back (if it is running, otherwise the statement will return ‘no rows’).

    Check replication

    Check replication

Netbeans + Visual Paradigm = EJB Tutorial (Part 4)

Based on the previous parts of this tutorial (1, 2, 3) we will modify the application and Glassfish to connect to PostgreSQL or Oracle as DB.

  • Preparing Glassfish libraries
    Download the drivers for Oracle and PostgreSQL and add them to your {GLASSFISHHOME}/domains/{YOURDOMAIN}/lib
    Restart Glassfish.

    Glassfish lib folder

    Continue reading

Netbeans + Visual Paradigm = EJB Tutorial (Part 3)

In part 1 of this tutorial we created an EJB using Netbeans and Visual Paradigm, in part 2 a little ZK application to read data using the EJB. In part 3 we will move away from the Derby DB to PostgreSQL and Oracle DB and challenge ourselves with identifier more than 30 characters, which is an issue for Oracle (yes, it is 2011). We will add columns with more than 30 characters and play with a few different column types (the ones showing up in a normal DB layout).

  • Add new fields to the ERD
    this_is_a_very_long_remark_field
    floatcol
    numbercol

    Updated ERD

  • Continue reading

Installing pgAdminIII for PostgreSQL 9 on Ubuntu

pgAdmin is the best GUI you can use to administrate PostgreSQL, unffortunately the Ubuntu default packages still offer only PostgreSQL 8.4 and an older version of pgAdmin III that does not support PostgreSQL 9.0.x. Thanks to Martin Pitt who maintains the latest packages you can run and maintain the latest PostgreSQL versions.

If you run Maverick:

  • sudo apt-key adv –keyserver keyserver.ubuntu.com –recv-keys 8683D8A2
  • sudo apt-get update
  • sudo apt-get install pgadmin3

Check here for latest or other releases of Ubuntu.

Installing PostgreSQL 9.0 on Ubuntu

Thanks to Martin Pitt , who maintains the packages for Ubuntu, nstalling the latest version of PostgreSQL on Ubuntu (Lucid) is nothing more than updating your /etc/apt/sources.list with

deb http://ppa.launchpad.net/pitti/postgresql/ubuntu lucid main
deb-src http://ppa.launchpad.net/pitti/postgresql/ubuntu lucid main

plus

apt-get update

and

apt-get installpostgresql-9.0

I recommend reading the release notes and he outstanding good postgresql documentation.