0

Собираем кластер PostgreSQL для разработки и тестирования

09.08.2023

Сегодня СУБД PostgreSQL является одной из самых известных и популярных систем управления баз данными в мире. Открытый исходный код, отсутствие платы за использование, контроль целостности, репликация – это далеко не все преимущества данной СУБД. В современных реалиях, когда тема импортозамещения особенно актуальна, PostgreSQL может оказаться подходящим вариантом.

Обычно PostgreSQL разворачивают в качестве кластера – системы, которая состоит из нескольких связанных между собой компьютеров (серверов) с целью обеспечения отказоустойчивости.

Как правило, при развертывании кластеров PostgreSQL используют сторонние инструменты такие как Patroni, stolon, repmgr. 

В статье будет описана установка кластера PostgreSQL с помощью Ansible – инструмента, предназначенного для автоматизации настройки и развертывания программного обеспечения, а также инструмента repmgr, предназначенного для управления репликами и отказоустойчивостью в кластерах PostgreSQL.

В компаниях не всегда имеется возможность быстро выделить ресурсы для разворачивания ВМ, чтобы организовать рабочую среду для разработки или тестирования. Чтобы избежать излишней бюрократии, если такая имеет место быть, можно локально поднять систему и сразу приступить к работе с ней. Поэтому в статье в качестве примера приведен также алгоритм по установке и работе с утилитой Vagrant, которая позволяет быстро решить эту задачу.

Подготовка к установке

В качестве примера будет использоваться виртуальная машина с установленной операционной системой Ubuntu 20.04.3 LTS. Узлы кластера будут представлены в виде 3 виртуальных машин под управлением ОС Ubuntu 18.04 Bionic Beaver, которые будут запущены на гипервизоре VirtualBox. Сами ВМ будут развернуты при помощи Vagrant  утилиты, предназначенной для создания и конфигурирования виртуальных окружений (под виртуальным окружением понимается более стандартное понятие – виртуальная машина). Ниже описаны хосты, которые будут использоваться в качестве кластера PostgreSQL:

node1 192.168.56.11 Роль primary, она же мастер-нода;

node2 192.168.56.12 Роль standby. Обычная рабочая нода;

node3 192.168.56.13 Роль witness. В терминологии repmgr witness это нода, которая не является частью кластера и предназначена для выбора новой мастер-ноды в случае возникновения проблем с кластером.

Ниже перечислено ПО, которое будет использоваться в статье:

Ansible;

Vagrant;

VirtualBox;

PostgreSQL;

repmgr.

Сначала на управляющий хост (основной хост, с которого будет вестись управление Vagrant и Ansible) необходимо установить AnsibleVagrant и VirtualBox.

Произвести установку Ansible можно разными способами. В данном примере установка будет произведена при помощи официального репозитория ansible. Для этого необходимо выполнить следующие шаги:

1) Обновить списки пакетов:

sudo apt update

2) Установить пакет software-properties-common:

sudo apt -y install software-properties-common

3) Добавить официальный репозиторий Ansible:

sudo add-apt-repository --yes --update ppa:ansible/ansible

4) Установить Ansible:

sudo apt -y install ansible

После того как установка будет завершена, можно проверить, что Ansible установился корректно, путем вывода его версии. Для этого достаточно выполнить команду:

ansible --version

Если команда отобразила версию (первая строка с названием ansible [core <версия>]), значит, пакет успешно и без ошибок установлен в системе.

Далее необходимо установить Vagrant. Установка производится из официального репозитория. Шаги по установке Vagrant:

1) Добавить gpg ключ от официального репозитория Vagrant:

wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor | sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg

2) Добавить официальный репозиторий hashicorp:

echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list

3) Обновить список репозиториев и установить пакет vagrant:

sudo apt update && sudo apt -y install vagrant

После установки необходимо убедиться, что установка прошла успешно. Для этого в терминале необходимо ввести команду:

vagrant

Если команда вернула список команд и их описание, значит установка vagrant прошла успешно.

Последний шаг – установка VirtualBox. Необходимые пакеты уже присутствуют в официальных репозиториях. Для установки достаточно выполнить одну команду:

sudo apt -y install virtualbox virtualbox-dkms

Создание и подготовка Vagrantfile

Для создания виртуальных машин в vagrant используется специальный файл – vagranfile. Для его создания необходимо выполнить команду:

vagrant init

Команда сгенерирует специальный шаблон, где указываются ВМ, которые будут созданы. Также в этом файле прописываются имена хостов, IP адреса хостов и способ подключения к ним.

Содержимое файла будет следующим

Vagrant.configure("2") do |config|
  (1..3).each do |n|
	config.vm.define "node#{n}" do |define|
  	define.ssh.insert_key = false
  	define.vm.box = "ubuntu/bionic64"
  	define.vm.hostname = "node#{n}"
  	define.vm.network :private_network, ip: "192.168.56.1#{n}"
  	# if you would like to use port forwarding, uncomment the line below
  	# define.vm.network :forwarded_port, guest: 5432, host: "543#{n}"
 
  	define.vm.provider :virtualbox do |v|
    	v.cpus = 1
    	v.memory = 1024
    	v.name = "node#{n}"
  	end
 
  	if n == 3
    	define.vm.provision :ansible do |ansible|
      	ansible.limit = "all"
      	ansible.playbook = "playbook.yaml"
 
      	ansible.host_vars = {
        	"node1" => {:connection_host => "192.168.56.11",
                    	:node_id => 1,
                    	:role => "primary" },
 
        	"node2" => {:connection_host => "192.168.56.12",
                    	:node_id => 2,
  	                  :role => "standby" },
 
        	"node3" => {:connection_host => "192.168.56.13",
                    	:node_id => 3,
                    	:role => "witness" }
      	}
      	# to enable ansible playbook verbose mode, uncomment the line below
      	# ansible.verbose = "v"
    	end
  	end
 
	end
  end
end

Где:

define.ssh.insert_key – если выставлен в false, то vagrant не будет автоматически создавать и использовать собственные SSH ключи;

define.vm.box – задает имя образа для ВМ. Образы хранятся на сайте Vagrant Cloud;

define.vm.hostname – задает hostname виртуальным машинам;

define.vm.network – задает тип сети и диапазон IP адресов;

v.cpus – задает количество ядер, которое будет выделено для ВМ;

v.memory – задает количество оперативной памяти, которое будет выделено для ВМ;

ansible.playbook – прописывается полный путь до playbook Ansible. Vagrant имеет полную поддержку и интеграцию с Ansible;

ansible.host_vars – в данном блоке прописываются хосты, на которых будет запущен playbook Ansible. Эквивалентен файлу инвентаризации в Ansible.

Создание ролей в Ansible

Так как для установки и настройки кластера необходимо выполнить много действий, они будут разбиты на роли.

Роли в Ansible – это способ логического разбиения файлов или, проще говоря, независимая сущность, решающая какой-то набор задач. С технической точки зрения роль – это директория с поддиректориями и файлами, где расположены задачи.

Для удобства создадим директорию с именем postgres-cluster:

mkdir postgres-cluster

Далее необходимо перейти в созданный каталог и создать следующие директории:

mkdir group_vars
mkdir roles

В директории roles будут храниться все необходимые роли. В ней необходимо создать:

mkdir roles/postgres_12/tasks
mkdir roles/postgres_12/templates
mkdir roles/registration/tasks
mkdir roles/registration/templates
mkdir roles/repmgr/tasks
mkdir roles/repmgr/templates
mkdir roles/ssh/files/keys
mkdir roles/ssh/tasks

Начнем заполнять директории файлами с описанием необходимых действий (в терминологии Ansible каждая задача называется task). Но сначала необходимо заполнить файл с переменными. Они будут храниться в директории group_vars в файле с именем all.yaml.

Содержимое файла представлено ниже:

group_vars/all.yaml
node1_ip: "192.168.56.11"
node2_ip: "192.168.56.12"
node3_ip: "192.168.56.13"
pg_version: "12"

В переменных с именем node прописаны IP-адреса, которые будут присвоены виртуальным машинам. Переменная pg_version содержит версию PostgreSQL, которая будет установлена на хосты. В данном примере будет использоваться 12 версия.

Далее описываются роли. Для каждой роли в своей директории будет создана еще одна директория с именем roles, в которой будет находиться файл с именем main.yaml.Первая роль предназначена для установки PostgreSQL

roles/postgres_12/tasks/main.yaml
- name: Add PostgreSQL apt key
  apt_key:
	url: https://www.postgresql.org/media/keys/ACCC4CF8.asc
 
- name: Add PostgreSQL repository
  apt_repository:
	# ansible_distribution_release = xenial, bionic, focal
	repo: deb http://apt.postgresql.org/pub/repos/apt/ {{ ansible_distribution_release }}-pgdg main
 
- name: Install PostgreSQL 12
  apt:
	name: postgresql-12
	update_cache: yes
 
- name: Copy database configuration
  template:
	src: full_postgresql.conf.j2
	dest: /etc/postgresql/12/main/postgresql.conf
	group: postgres
	mode: '0644'
	owner: postgres
 
- name: Copy user access configuration
  template:
	src: pg_hba.conf.j2
	dest: /etc/postgresql/12/main/pg_hba.conf
	group: postgres
	mode: '0640'
	owner: postgres

Порядок действий, описанный в роли, следующий:

1) Добавление ключа от официального репозитория postgres;

2) Добавление официального репозитория postgres;

3) Установка PostgreSQL 12;

4) Копирование и использование конфигурационного файла full_postgresql.conf.j2, который заменит стандартный конфигурационный файл postgresql.conf;

5) Копирование и использование конфигурационного файла pg_hba.conf.j2, который заменит стандартный конфигурационный файл pg_hba.conf.

Конфигурационные файлы full_postgresql.conf.j2и pg_hba.conf.j2будут находиться по следующему пути: roles/postgres_12/templates.Содержимое файлов описано ниже

roles/postgres_12/templates/full_postgresql.conf.j2
data_directory = '/var/lib/postgresql/12/main'
hba_file = '/etc/postgresql/12/main/pg_hba.conf'
ident_file = '/etc/postgresql/12/main/pg_ident.conf'
external_pid_file = '/var/run/postgresql/12-main.pid'
port = 5432
max_connections = 100
unix_socket_directories = '/var/run/postgresql'
shared_buffers = 128MB
dynamic_shared_memory_type = posix          	
# repmgr
listen_addresses = '*'
shared_preload_libraries = 'repmgr'
wal_level = replica
max_wal_senders = 5
wal_keep_segments = 64
max_replication_slots = 5
hot_standby = on
wal_log_hints = on

Строки под комментарием # repmgr относятся к настройкам утилиты repmgr и предназначены для настройки репликации.

В конфигурационном файле pg_hba.conf.j2 прописаны сетевые доступы до всех нод кластера.

Следующая задача – создание SSH ключей для подключения к виртуальным машинам. Сначала на хостовой ОС необходимо сгенерировать SSH ключи. Команда ниже эквивалента команде ssh-keygen с той лишь разницей, что команда ниже сгенерирует ключи без интерактивного режима:

ssh-keygen -q -t rsa -f ~/.ssh/id_rsa <<<y >/dev/null 2>&1

Закрытый (id_rsa) и открытый (id_rsa.pub) ключи будут сохранены по умолчанию — в домашней директории пользователя в скрытой директории .ssh

Далее необходимо скопировать файл с открытым и закрытым ключом в директорию  /roles/ssh/files/keys Итого в поддиректории keys будет два файла — id_rsa и id_rsa.pub.Роль по использованию SSH ключей описана ниже

roles/ssh/tasks/main.yaml
- name: Install OpenSSH
  apt:
	name: openssh-server
	update_cache: yes
	state: present
 
- name: Create postgres SSH directory
  file:
	mode: '0755'
	owner: postgres
	group: postgres
	path: /var/lib/postgresql/.ssh/
	state: directory
 
- name: Copy SSH private key
  copy:
	src: "keys/id_rsa"
	dest: /var/lib/postgresql/.ssh/id_rsa
	owner: postgres
	group: postgres
	mode: '0600'
 
- name: Copy SSH public key
  copy:
	src: "keys/id_rsa.pub"
	dest: /var/lib/postgresql/.ssh/id_rsa.pub
	owner: postgres
	group: postgres
	mode: '0644'
 
- name: Add key to authorized keys file
  authorized_key:
	user: postgres
	state: present
	key: "{{ lookup('file', 'keys/id_rsa.pub') }}"
 
- name: Restart SSH service
  service:
	name: sshd
	enabled: yes
	state: restarted

Порядок действий, описанный в роли, следующий:

1) Установка пакета OpenSSH.

2) Создание директории, где будут храниться SSH ключи – /var/lib/postgresql/.ssh/;

3) Копирование закрытого ключа в директорию /var/lib/postgresql/.ssh/;

4) Копирование открытого ключа в директорию /var/lib/postgresql/.ssh/;

5) Добавление открытого ключа в файл authorized_key;

6) Перезапуск демона sshd.

Следующая задача – установка и настройка repmgr.Посмотреть

roles/repmgr/tasks/main.yaml

- name: Download repmgr repository installer

  get_url:

	dest: /tmp/repmgr-installer.sh

	mode: 0700

	url: https://dl.2ndquadrant.com/default/release/get/deb

 

- name: Execute repmgr repository installer

  shell: /tmp/repmgr-installer.sh

 

- name: Install repmgr for PostgreSQL {{ pg_version }}

  apt:

	name: postgresql-{{ pg_version }}-repmgr

	update_cache: yes

 

- name: Setup repmgr user and database

  become_user: postgres

  ignore_errors: yes

  shell: |

	createuser --replication --createdb --createrole --superuser repmgr &&

	psql -c 'ALTER USER repmgr SET search_path TO repmgr_test, "$user", public;' &&

	createdb repmgr --owner=repmgr

- name: Copy repmgr configuration

  template:

	src: repmgr.conf.j2

	dest: /etc/repmgr.conf

 

- name: Restart PostgreSQL

  systemd:

	name: postgresql

	enabled: yes

    state: restarted

Порядок действий, описанный в роли, следующий:

1) Скачивание установщика, содержащего официальный репозиторий repmgr;

2) Запуск скачанного установщика;

3) Установка пакета repmgr для 12 версии PostgreSQL;

4) Инициализация и создание репликационного кластера;

5) Копирование и использование конфигурационного файла repmgr.conf.j2, который заменит стандартный конфигурационный файл repmgr.conf;

6) Перезапуск демона PostgreSQL.

Конфигурационный файл repmgr.conf.j2 будет находиться по следующему пути roles/repmgr/templatesСодержимое файла описано ниже

roles/repmgr/templates/repmgr.conf.j2
node_id = {{ node_id }}
node_name = 'node{{ node_id }}'
conninfo = 'host={{ connection_host }} user=repmgr dbname=repmgr'
data_directory = '/var/lib/postgresql/{{ pg_version }}/main'
use_replication_slots = yes
reconnect_attempts = 5
reconnect_interval = 1
failover = automatic
pg_bindir = '/usr/lib/postgresql/{{ pg_version }}/bin'
promote_command = 'repmgr standby promote -f /etc/repmgr.conf'
follow_command = 'repmgr standby follow -f /etc/repmgr.conf'
log_level = INFO
log_file = '/var/log/postgresql/repmgr.log'
 
#monitoring_history=yes
#monitor_interval_secs=5
#log_status_interval=5
#promote_check_timeout=5
#promote_check_interval=1
#master_response_timeout=5

Последняя роль – это присвоение ролей нодам кластера.Посмотреть

roles/repmgr/registration/main.yaml
- name: Register primary node
  become_user: postgres
  shell: repmgr primary register
  ignore_errors: yes
  when: role == "primary"
 
- name: Stop PostgreSQL
  systemd:
	name: postgresql
	state: stopped
  when: role == "standby"
 
- name: Clean up PostgreSQL data directory
  become_user: postgres
  file:
	path: /var/lib/postgresql/{{ pg_version }}/main
	force: yes
	state: absent
  when: role == "standby"
 
- name: Clone primary node data
  become_user: postgres
  shell: repmgr -h {{ node1_ip }} -U repmgr -d repmgr standby clone
  ignore_errors: yes
  when: role == "standby"
 
- name: Start PostgreSQL
  systemd:
	name: postgresql
	state: started
  when: role == "standby"
 
- name: Register {{ role }} node
  become_user: postgres
  shell: repmgr -h {{ node1_ip }} {{ role }} register -F
  ignore_errors: yes
  when: role != "primary"
 
- name: Start repmgrd
  become_user: postgres
  shell: repmgrd
  ignore_errors: yes

Порядок действий, описанный в роли, следующий:

1) Регистрация primary ноды (она же мастер-нода).

2) Остановка демона PostgreSQL.

3) Удаление всех данных из директории /var/lib/postgresql/12/main.

4) Регистрация stan-by ноды.

5) Запуск демона PostgreSQL.

6) Запуск демона repmrg.

Создание и запуск playbook

Чтобы собрать все задачи воедино, необходимо создать один общий playbook, в который будут включены все задачи и файлы, что были созданы ранее. Для этого в корневой директории (в данном примере это директория с именем postgres-cluster) необходимо создать файл с именем playbook.yaml со следующим содержанием:

postgres-cluster/playbook.yaml
---
- hosts: all
  gather_facts: yes
  become: yes
  roles:
	- postgres_12
	- ssh
	- repmgr
	- registration

В параметре roles перечислены все роли, которые будут запущены на хостах. Обратите внимание на порядок ролей.

В итоге получится следующая структура файлов:

Также в корневой директории присутствует ранее созданный Vagrantfile.

Когда все файлы будут созданы, можно запускать установку виртуальных машин и playbook Ansible. Для этого достаточно выполнить одну команду:

vagrant up

Начнется процесс установки (см. скриншот ниже). Сначала будут созданы 3 виртуальные машины, далее будет запущен playbook, который установит СУБД PostgreSQL, утилиту repmgr и настроит репликацию.

Ниже показан процесс запуска ролей Ansible:

После того как установка будет завершена, можно подключиться к любой из 3 созданных ВМ для проверки статуса репликации. Для этого необходимо ввести команду vagrant ssh node1, где node1 — это имя хоста одной из ВМ:

При подключении по SSH пароль вводить не нужно, так как был настроен вход по SSH ключам.

Для проверки статуса кластера и репликации необходимо выполнить команду:

repmgr service status

Как видно из вывода команды, у нас создался кластер PostgreSQL с 3 нодами. У каждой ноды своя роль (столбец Role).

Итог

Созданный кластер можно использовать в качестве тестовой инсталляции, а также для знакомства с утилитой репликации repmgr. Роли нод кластера при желании можно поменять. Также можно легко производить горизонтальное масштабирование – добавлять новые ноды кластера.

Свежие комментарии

Подписка

Лучшие статьи

Рубрики

Популярное

Previous Story

Поиск в Linux с помощью команды find

Next Story

Создание кластера Postgres на CentOS с помощью Patroni + Consul

Latest from Blog

Настройка простого беспроводного репитера на устройстве MikroTik

При развертывании беспроводных сетей достаточно часто возникают ситуации, когда в некоторых местах квартиры или офиса мощность Wi-Fi сигнала недостаточна для уверенной работы. Конечно, наиболее действенным решением является создание централизованно управляемой сети и

Настройка и использование Redis

В этой статье мы расскажем что такое Redis, его преимущества и для каких целей он используется. Redis (REmote DIctionary Server) — сетевое журналируемое хранилище данных типа “ключ” — “значение” с открытым исходным кодом. По сути Redis представляет собой базу данных

Настройка и использование Memcached

В статье мы расскажем, что такое Memcache, зачем он нужен и как он влияет на работу некоторых популярных CMS. Кеширование данных – немаловажный момент в работе любого веб-проекта. С ростом посещаемости увеличиваются требования к

Как настроить логирование и ротацию логов Nginx

Вовремя настроенное журналирование позволяет в дальнейшем избежать неожиданных проблем с веб-сервером. Информация, хранящаяся в логах (или журналах) сервера, помогает быстро оценить ситуацию и устранить ошибки. В этой статье мы рассмотрим возможности логирования

Распределение выполнения запросов внутри приватной сети VPS через HAProxy

Приватную сеть можно использовать для распределения выполнения загрузки и балансировки запросов между несколькими серверами. Рассмотрим организацию такой балансировки на примере HAProxy – бесплатного ПО, предназначенного для распределения нагрузки и организации проксирования TCP-пакетов между несколькими обслуживающими
Go toTop