postgresql 主備及切換-恢復方案

前言

前期的gitlab 已經開始推廣測試，最近對postgresql 做了主備，這里說下方案及在實施過程中遇到的坑。
postgresql 的具安裝不在此介紹。

基礎信息

    primary_ip： 192.168.10.2，
    standby_ip： 192.168.10.3，
    PGDATA： /opt/gitlab/postgresql/data，
    postgresql_version：(PostgreSQL) 9.6.8，
    PGCONF_DIR: $PGDATA，

涉及修改的配置文件有：

1. postgresql.conf --------- postgresql 主配置文件
2. pg_hba.conf ------------- postgresql 訪問規則文件
3. recovery.conf ----------- postgresql 備庫訪問主庫配置文件

注意事項！

    1. 主備postgresql 版本需保持一致！
    2. postgresql.conf 配置文件需保持一致！
    3. 備庫提權為主庫后，切記不要直接啟動原主庫！

準備操作

在primary 192.168.10.2 主機操作

1.為備庫準備主庫，修改配置文件

cat postgresql.conf

    wal_level = hot_standby         # minimal, replica, or logical
    max_wal_senders = 2     # max number of walsender processes
    hot_standby = on            # "on" allows queries during recovery
    max_connections = 300           # (change requires restart)
    archive_mode = on
    restore_command = ''

cat pg_hba.conf

    host    all             all             127.0.0.1/32            trust
    host    all             all             ::1/128                     trust
    host    replication     gitlab_replicator    192.168.10.3/32    trust

cat recovery.done

    restore_command = ''
    recovery_target_timeline = 'latest'
    standby_mode = on
    primary_conninfo = 'host=192.168.10.3 port=5432 user=gitlab_replicator'

2.創建用于復制的帳號，并賦予replication 權限

    postgres=#CREATE USER gitlab_replicator REPLICATION LOGIN;

3.基本備份為備庫準備引導數據

    postgres=#SELECT pg_start_backup(back_20180929);
    cd  /opt/gitlab/postgresql && tar zcf base_data.tar.gz data
    postgres=#SELECT pg_start_stop();

在 standby 192.168.10.3 主機操作

1.解壓基本數據
將主庫上創建的base_data.tar.gz上傳到備庫主機，并解壓到數據目錄
tar zxf base_data.tar.gz -C /opt/gitlab/postgresql/

2.修改配置文件
注： postgresql.conf 文件內此部分一定要與主庫的配置保持一致，否則可能會在主從切換恢復時產生錯誤

cat postgresql.conf

    wal_level = hot_standby         # minimal, replica, or logical
    max_wal_senders = 2     # max number of walsender processes
    hot_standby = on            # "on" allows queries during recovery
    max_connections = 300           # (change requires restart)
    archive_mode = on
    restore_command = ''

cat pg_hba.conf

    host    all             all             127.0.0.1/32            trust
    host    all             all             ::1/128                     trust
    host    replication     gitlab_replicator    192.168.10.2/32    trust

cat recovery.conf

    restore_command = ''
    recovery_target_timeline = 'latest'
    standby_mode = on
    primary_conninfo = 'host=192.168.10.2 port=5432 user=gitlab_replicator'

3.啟動備庫，在主庫執行sql，并在備庫驗證

主從切換

主備庫的判斷是根據當前是否存在recovery.conf文件
在將備庫提升為主庫時，會自動重命名recovery.conf文件為recovery.done。同時要將主庫降為備庫，降備方式為重命名recovery.done文件
mv recover.done recovery.conf
這樣在處理完主庫故障后，才會將提升到主庫的更新數據同步過來

這里提供個簡單的思路及腳本，前提是假設主備之間不存在網絡故障,且不存在同時為主或備的情況
判斷主庫的狀態
1.為shut down 時
判斷備庫是否為in archive recovery并執行將主庫降為備庫，將備庫升為主庫，其余狀態發送報警
2.為in production時
判斷備庫是否為in archive recovery，其余狀態發送報警
3.為in archive recovery時
判斷備庫是否為in production，其余狀態發送報警
4.為shut down in recovery時
發送報警

shell script

    #!/bin/bash
    PRIMARY_IP="192.168.10.2"
    STANDBY_IP="192.168.10.3"
    PGDATA="/DATA/postgresql/data"
    SYS_USER="root"
    PG_USER="postgresql"
    PGPREFIX="/opt/pgsql"

    pg_status()
    {
            ssh ${SYS_USER}@$1 /
            "su - ${PG_USER} -c '${PGPREFIX}/bin/pg_controldata -D ${PGDATA} /
            | grep cluster' | awk -F : '{print \$2}' | sed 's/^[ \t]*\|[ \t]*$//'"
    }

    # recover to primary
    recovery_primary()
    {
            ssh ${SYS_USER}@$1 /
            "su - ${PG_USER} -c '${PGPREFIX}/bin/pg_ctl promote -D ${PGDATA}'"
    }

    # primary to recovery
    primary_recovery()
    {
            ssh ${SYS_USER}@$1 /
            "su - ${PG_USER} -c 'cd ${PGDATA} && mv recovery.done recovery.conf'"
    }

    send_mail()
    {
            echo "send SNS"
    }

    case "`pg_status ${PRIMARY_IP}`" in
            "shut down")
                    case "`pg_status ${STANDBY_IP}`" in
                            "in archive recovery")
                                    primary_recovery ${PRIMARY_IP}
                                    recovery_primary ${STANDBY_IP}
                                    ;;
                            "shut down in recovery"|"in production")
                                    send_mail
                                    ;;
                    esac
                    ;;
            "in production")
                    case "`pg_status ${STANDBY_IP}`" in
                            "shut down in recovery"|"shut down"|"in production")
                                    send_mail
                                    ;;
                    esac
                    echo "primary"
                    ;;
            "in archive recovery")
                    case "`pg_status ${STANDBY_IP}`" in
                            "shut down")
                                    primary_recovery ${STANDBY_IP}
                                    recovery_primary ${PRIMARY_IP}
                                    ;;
                            "shut down in recovery"|"in archive recovery")
                                    send_mail
                                    ;;
                    esac
                    echo "recovery"
                    ;;
            "shut down in recovery")
                    case "`pg_status ${STANDBY_IP}`" in
                            "shut down in recovery"|"shut down"|"in archive recovery")
                                    send_mail
                                    ;;
                    esac
                    echo "recovery down"
                    ;;
    esac

報錯處理

error 1

FATAL:  no pg_hba.conf entry for replication connection from host "192.168.1.2", user "standby", SSL off

需要將用戶加入到192.168.1.2的pg_hba.conf文件內，并配置好認證方式及口令

error 2

FATAL:  database system identifier differs between the primary and standby
DETAIL:  The primary's identifier is 6589099331306617531, the standby's identifier is 6605061381709180314

這是因為在將備庫提升為主庫后，將原先的主庫恢復為主庫時沒有完全將缺少的數據同步過來導致的

error 3

FATAL:  number of requested standby connections exceeds max_wal_senders (currently 0)

FATAL:  hot standby is not possible because max_connections = 100 is a lower setting than on the master server (its value was 200)

FATAL:  hot standby is not possible because max_locks_per_transaction = 64 is a lower setting than on the master server (its value was 128)

這是因為備庫的數量超過主庫配置的允許備庫最大連接數量了
這里配置的為0
此問提出現在將備庫升為主庫后，將原主庫降為備庫同步數據時，因此需要注意這部分的配置主備要一致

后記

postgresql 主主同步需要使用三方中間件實現，有需要的可查詢相關資料

本文參考資料為postgresql 官方文檔