Category Archive Базы данных

Автор:human

Postgresql 9.5 репликация-pgpool+keepalived на debian/ubuntu

Postgresql 9.5 репликация-pgpool+keepalived на debian/ubuntu

Postgresql 9.5 репликация-pgpool+keepalived на debian_ubuntu-4
Postgresql 9.5 репликация-pgpool+keepalived на debian_ubuntu-3 Postgresql 9.5 репликация-pgpool+keepalived на debian_ubuntu-2 Postgresql 9.5 репликация-pgpool+keepalived на debian_ubuntu-1

1. Конфигурация.

ОС — DEBIAN SERVER 8 MINIMAL
10.4.1.173 — Виртуальный ip адрес за счет keepalived
НОДЫ:
PGPOOL1 10.4.1.171 — нода с pgpool+keepalived
PGPOOL1 10.4.1.172 — нода с pgpool+keepalived
pg1 10.4.1.161 — master postgresqldatabase
pg2 10.4.1.162 — master postgresqldatabase

2. Установка и настройка.

2.1 Тюнинг операционных систем.

Обязательно устанавливаем ntp для синхронизации времени.

sudo apt-get install ntp  iptables-persistent -y

Настраиваем sysctk.conf

sudo nano /etc/sysctl.conf

Вставляем в конце

kernel.shmmni = 4096

kernel.sem = 50100 64128000 50100 1280

fs.file-max = 7672460

net.ipv4.ip_local_port_range = 9000 65000

net.core.rmem_default = 1048576

net.core.rmem_max = 4194304

net.core.wmem_default = 262144

net.core.wmem_max = 1048576

net.ipv4.tcp_tw_recycle = 1

net.ipv4.tcp_max_syn_backlog = 4096

net.core.netdev_max_backlog = 10000

vm.overcommit_memory = 0

net.ipv4.ip_conntrack_max = 655360

fs.aio-max-nr = 1048576

net.ipv4.tcp_timestamps = 0

Применяем

sysctl -p

Настраиваем ограничения

nano /etc/

Настраиваем фаервол:

Создадим пользователя postgres на нодах

adduser postgres —home /home/postgres
sudo chown postgres /home/postgres
sudo chgrp postgres /home/postgres

Настроим  доступ по ssh ключам. Как это сделать смотрим в этой статье

Все теперь наши pg1 и pg2 могут свободно заходить по ssh ключам через пользователся postgres. Проверьте, например с pg1 сделайте.

ssh postgres@10.4.1.162

Идем далее.

 

О кластеризации и репликации мною было уже много сказано, но вот опять наткнулся на старые грабли — нужен кластер PostgreSQL. Решил решить данную задачку посредством Pgpool-II, только вот проблема — документации на офф. сайте сего продукта японской мысли оказалось с гулькин нос, да и та вся либо на японском, либо на англицком. Итак, предположим что данное чудо-юдо, ровно как и слоняры у нас уже установлены на всех узлах (у меня узлов будет 2, поэтому из соображений High Availablity pgpool установлен будет на обоих), слоновьи сервера уже настроены.

* Настройки идентичны для обоих узлов. На обеих машинах стоит RHEL 6.2.

pcp.conf У pgpool-II есть интерфейс для административных целей — получить информацию об узлах базы данных, остановить pgpool-II и т.д. — по сети.
Чтобы использовать команды PCP, необходима идентификация пользователя. Эта идентификация отличается от идентификации пользователей в PostgreSQL. Имя пользователя и пароль нужно указывать в файле pcp.conf. В этом файле имя пользователя и пароль указываются как пара значений, разделенных двоеточием (:). Одна пара в строке.
Пароли зашифрованы в формате хэша md5.

Код:
# cat /etc/pgpool-II/pcp.conf
postgres:e8a48653851e28c69d0506508fb27fc5

При установке pgpool-II автоматически создается файл pcp.conf.sample. Его необходимо скопировать его в файл pcp.conf и отредактировать. Для шифрования пароля в хэш md5 используется команда pg_md5 (один из компонентов pgpool-II). pg_md5 принимает текст в параметре командной строки и отображает текст его md5 хэша.
Например:

Код:
# pg_md5 postgres
e8a48653851e28c69d0506508fb27fc5

Этот хэш вставляем в pcp.conf.

Команды PCP выполняются по сети, так что в файле pgpool.conf нужно будет задать номер порта в параметре pcp_port. Я заюзал стандартные.

Код:
pcp_port = 9898

pgpool.conf — Основной конфиг программы. У меня он приведен к сл. виду:

Код:
# cat /etc/pgpool-II/pgpool.conf
listen_addresses = ‘*’ # Слушаем все адреса, ибо слушать localhost смысла нет, а тут либо он, либо все
port = 5432 # Вешаем на стандартный порт pgsql. Слоняры будут у меня слушать порт 5433

socket_dir = ‘/tmp’
pcp_port = 9898  # Cм. выше
pcp_socket_dir = ‘/tmp’

enable_pool_hba = off # Отключаем встроеный механизм авторизации — она будет происходить на серверах баз данных
authentication_timeout = 60
ssl = off
#ssl_key = ‘./server.key’
#ssl_cert = ‘./server.cert’
#ssl_ca_cert = »
#ssl_ca_cert_dir = »

#——————————————————————————
# Настройки пулов
#——————————————————————————
num_init_children = 32
max_pool = 4
child_life_time = 300
child_max_connections = 0
connection_life_time = 0
client_idle_limit = 0

#——————————————————————————
# Логи
#——————————————————————————
log_destination = ‘syslog’
print_timestamp = on
log_connections = on
log_hostname = on
log_statement = on
log_per_node_statement = on
log_standby_delay = ‘always’

syslog_facility = ‘LOCAL0’
syslog_ident = ‘pgpool’
debug_level = 1

#——————————————————————————
# Что куда кладем
#——————————————————————————

pid_file_name = ‘/var/run/pgpool-II/pgpool.pid’
logdir = ‘/var/log/pgpool-II’

#——————————————————————————
# Пулинг соединений
#——————————————————————————

connection_cache = on
reset_query_list = ‘ABORT; DISCARD ALL’
#reset_query_list = ‘ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT’

#——————————————————————————
# Режим репликации — его и будем использовать. В данном
# режиме все модифицирующие запросы типа UPDATE,
# DELETE, INSERT отправляются сразу на все узлы баз даных,
# а запросы SELECT рулятся исходя из настроек ниже
#——————————————————————————

replication_mode = on # Включаем
replicate_select = off # Реплицировать-ли SELECT?
# Мне это не нужно, я буду юзать режим LB (см. ниже)
insert_lock = on
lobj_lock_table = »
replication_stop_on_mismatch = off
failover_if_affected_tuples_mismatch = off

#——————————————————————————
# Распределение нагрузки
#——————————————————————————

load_balance_mode = on #  распределяем SELECT между узлами базы данных.
ignore_leading_white_space = on
white_function_list = »
black_function_list = ‘nextval,setval’

#——————————————————————————
# MASTER/SLAVE — Горизонтальная репликация
#——————————————————————————

master_slave_mode = off # Нам оно не нужно
master_slave_sub_mode = ‘slony’
sr_check_period = 0
sr_check_user = ‘nobody’
sr_check_password = »
delay_threshold = 0
follow_master_command = »

#——————————————————————————
# Параллельные запросы и кэширование
#——————————————————————————

parallel_mode = off
enable_query_cache = off
pgpool2_hostname = »
system_db_hostname = ‘localhost’
system_db_port = 5432
system_db_dbname = ‘pgpool’
system_db_schema = ‘pgpool_catalog’
system_db_user = ‘pgpool’
system_db_password = »

#——————————————————————————
# Проверка состояния.
#——————————————————————————

health_check_period = 0
health_check_timeout = 20
health_check_user = ‘nobody’
health_check_password = »

#——————————————————————————
# Фэйловеры
#——————————————————————————

failover_command = »
# Executes this command at failover
# Special values:
#   %d = node id
#   %h = host name
#   %p = port number
#   %D = database cluster path
#   %m = new master node id
#   %H = hostname of the new master node
#   %M = old master node id
#   %P = old primary node id
#   %% = ‘%’ character
failback_command = »
# Executes this command at failback.
# Special values:
#   %d = node id
#   %h = host name
#   %p = port number
#   %D = database cluster path
#   %m = new master node id
#   %H = hostname of the new master node
#   %M = old master node id
#   %P = old primary node id
#   %% = ‘%’ character

fail_over_on_backend_error = off

#——————————————————————————
# Автовосстановление — тоже не наш случай
#——————————————————————————

recovery_user = ‘nobody’
recovery_password = »

recovery_1st_stage_command = »

recovery_2nd_stage_command = »

recovery_timeout = 90

client_idle_limit_in_recovery = 0

#——————————————————————————
# Узлы — тут думаю все понятно :)
#——————————————————————————

relcache_expire = 0

backend_hostname0 = ‘192.168.50.1’
backend_port0 = 5433
backend_weight0 = 1
backend_flag0= ‘ALLOW_TO_FAILOVER’
backend_hostname1 = ‘192.168.50.3’
backend_port1 = 5433
backend_weight1 = 1
backend_flag1= ‘ALLOW_TO_FAILOVER’

Файлик pool_hba.conf оставляем нетронутым, поскольку в конфиге выше мы отключили его использование, однако стоит сказать, что синтаксис его идентичен pg_hba.conf от PostgreSQL. Кстати, пора им заняться

Код:
# cat /var/lib/pgsql/data/pg_hba.conf
# PostgreSQL Client Authentication Configuration File
# ===================================================
#
# Refer to the «Client Authentication» section in the PostgreSQL
# documentation for a complete description of this file.  A short
# synopsis follows.
#
# This file controls: which hosts are allowed to connect, how clients
# are authenticated, which PostgreSQL user names they can use, which
# databases they can access.  Records take one of these forms:
#
# local      DATABASE  USER  METHOD  [OPTIONS]
# host       DATABASE  USER  ADDRESS  METHOD  [OPTIONS]
# hostssl    DATABASE  USER  ADDRESS  METHOD  [OPTIONS]
# hostnossl  DATABASE  USER  ADDRESS  METHOD  [OPTIONS]
#
# (The uppercase items must be replaced by actual values.)
#
# The first field is the connection type: «local» is a Unix-domain
# socket, «host» is either a plain or SSL-encrypted TCP/IP socket,
# «hostssl» is an SSL-encrypted TCP/IP socket, and «hostnossl» is a
# plain TCP/IP socket.
#
# DATABASE can be «all», «sameuser», «samerole», «replication», a
# database name, or a comma-separated list thereof. The «all»
# keyword does not match «replication». Access to replication
# must be enabled in a separate record (see example below).
#
# USER can be «all», a user name, a group name prefixed with «+», or a
# comma-separated list thereof.  In both the DATABASE and USER fields
# you can also write a file name prefixed with «@» to include names
# from a separate file.
#
# ADDRESS specifies the set of hosts the record matches.  It can be a
# host name, or it is made up of an IP address and a CIDR mask that is
# an integer (between 0 and 32 (IPv4) or 128 (IPv6) inclusive) that
# specifies the number of significant bits in the mask.  A host name
# that starts with a dot (.) matches a suffix of the actual host name.
# Alternatively, you can write an IP address and netmask in separate
# columns to specify the set of hosts.  Instead of a CIDR-address, you
# can write «samehost» to match any of the server’s own IP addresses,
# or «samenet» to match any address in any subnet that the server is
# directly connected to.
#
# METHOD can be «trust», «reject», «md5», «password», «gss», «sspi»,
# «krb5», «ident», «peer», «pam», «ldap», «radius» or «cert».  Note that
# «password» sends passwords in clear text; «md5» is preferred since
# it sends encrypted passwords.
#
# OPTIONS are a set of options for the authentication in the format
# NAME=VALUE.  The available options depend on the different
# authentication methods — refer to the «Client Authentication»
# section in the documentation for a list of which options are
# available for which authentication methods.
#
# Database and user names containing spaces, commas, quotes and other
# special characters must be quoted.  Quoting one of the keywords
# «all», «sameuser», «samerole» or «replication» makes the name lose
# its special character, and just match a database or username with
# that name.
#
# This file is read on server startup and when the postmaster receives
# a SIGHUP signal.  If you edit the file on a running system, you have
# to SIGHUP the postmaster for the changes to take effect.  You can
# use «pg_ctl reload» to do that.

# Put your actual configuration here
# ———————————-
#
# If you want to allow non-local connections, you need to add more
# «host» records.  In that case you will also need to make PostgreSQL
# listen on a non-local interface via the listen_addresses
# configuration parameter, or via the -i or -h command line switches.

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# «local» is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host    all             all             127.0.0.1/32            ident
# IPv6 local connections:
host    all             all             ::1/128                 ident
# Allow replication connections from localhost, by a user with the
# replication privilege.
#local   replication     postgres                                peer
#host    replication     postgres        127.0.0.1/32            ident
#host    replication     postgres        ::1/128                 ident
host     all             all             192.168.50.1/32         ident
host     all             all             192.168.50.3/32         ident

Обратите внимание на последние 2 строки — в них сказано что пользователей приходящих с машин 192.168.50.1 и 192.168.50.3 необходимо пропускать через авторизацию. Если вы не такой параноик как я можете выставить trust, тогда пользователи БД будут выполнять запросы без авторизации

У меня PostgreSQL 9.1.3 и pgpool-II соответствующей ему версии (а это поверьте мне важно) установлены из моего локального репозитория для RHEL (собственной сборки), поэтому учтите, что пути могут отличаться от стандартных.

High Availablity
Для того, чтобы при выпадении одного из узлов базы оставались доступными нам необходимо настроить heartbeat (кто-то может воспользоваться ucarp — дело вкуса).
Конфиг его у меня выглядит сл. образом на обоих узлах:

Код:
# cat /etc/ha.d/ha.cf
debugfile /var/log/ha-debug
logfile /var/log/ha-log

#logfacility    local0
keepalive 2
deadtime 30
warntime 10
initdead 120
udpport 694
baud    19200

bcast   eth1

auto_failback on

node    host1.domain.tld
node    host2.domain.tld

max_rexmit_delay 1000
deadping 30
debug 0

Тут думаю не составит труда разобраться используя официальную документацию. Все самое интересное — в следующем файле:

Код:
# cat /etc/ha.d/haresources
#node-name resource1 resource2 … resourceN
host1.domain.tld IPaddr::192.168.50.254/24/eth1 pgpool

Как видите присваиваем интерфейсу алиас в виде адреса 192.168.50.254 и основным владельцем назначаем хост1. В случае выпадения его поднимет у себя хост2 и запустит pgpool.

Вносим правки в /etc/hosts

Код:
# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain mx1.torrents.kg
192.168.50.254    pgpool.domain.tld
192.168.50.1    host1.domain.tld
192.168.50.3    host2.domain.tld

Проводим последние приготовления (на обоих узлах):

Код:
# chkconfig postgresql on
# chkconfig pgpool off
# chkconfig heartbeat on

Ну и стартуем:

Код:
# service postgresql start && ssh 192.168.50.3 /etc/init.d/postgresql start
# service heartbeat start && ssh 192.168.50.3 /etc/init.d/heartbeat start

Если с настройками все верно, на 1-м хосте должен будет запуститься pgpool

Код:
# netstat -nltp | grep pgpool
tcp        0      0 0.0.0.0:9898                0.0.0.0:*                   LISTEN      685/pgpool: wait fo
tcp        0      0 0.0.0.0:5432                0.0.0.0:*                   LISTEN      685/pgpool: wait fo

и добавиться алиас к интерфейсу eth1

Код:
# ip addr show
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN qlen 10000
link/ether bc:30:5b:68:e1:71 brd ff:ff:ff:ff:ff:ff
inet 192.168.50.1/24 brd 192.168.50.255 scope global eth1
inet 192.168.50.254/24 brd 192.168.50.255 scope global eth1:0
inet6 fe80::be30:5bff:fe68:e171/64 scope link
valid_lft forever preferred_lft forever

Тестируем.

Код:
#su postgres
$ createdb -p 5432 -h pgpool.domain.tld test # выполнить только на одной машине
$ psql -p 5433 -d test

Если последняя команда вам выдала что-то вроде

Код:
psql: СБОЙ:  база данных «test» не существует

это повод для пересмотра конфигов и глубокого изучения логов.

Если все верно и на обоих машинах psql без проблем подключается к базе test

Код:
psql (9.1.3)
Введите «help», чтобы получить справку.

test-# \q

Автор:human

Репликация и балансировка в Postgresql 9.5

Настройка репликации Postgresql 9.5 на debian 8

С репликацией у postgresql пока не все просто, но она работает. Рассмотрим всё на примере.

1.Конфигурация

ОС debian 8 jessie
node1 — 10.4.1.161 — postgresql master
node2- 10.4.1.162 — postgresql standby1
node3- 10.4.1.163 — postgresql standby2
10.4.1.180 — ваш пк для проверки баз на репликацию, например через pgadmin3.

2.Добавляем репы postgresq 9.5

Добавляем репы Postgres(на 2 ноды)

3. Настройка нод

Создадим папку для пользователя postgres до установки его (на обе ноды)

Ставим Postgresql 9.5

Создадим ключ для авторизации пользователей postgres(на 2 нодах)

ВНИМАНИЕ!!! СОЗДАЕМ КЛЮЧИ на обоих БЕЗ ПАРОЛЬНОЙ ФРАЗЫ!!!

Переход на NODE1

Переход на NODE2

Переход NODE1

Таким же образом добавим 3 ноду — суть такая — все ноды должны подключаться друг к другу через пользователя postgres,
!!!!!!!!!а также необходимо добавить ключ для подключения postgresql к root!!!!!
Редактим конфиг:

В любой точке файла (только не в конце) поместите следующие строки, которые откроют новому пользователю доступ к этому серверу:

Save (ctrl+o)
Отредактируем конфиг postgres

Найдите в нём следующие параметры, раскомментируйте их и измените их значения таким образом:

Save(ctrl+o)
Далее открываем psql:

Меняем пароль пользователя postgres:

Перезапускаем PostgreSQL:

Мастер настроен!

Переход на NODE2

Останавливаем PostgreSQL:

Становимся пользователем postgres(вы должны были заранее,как говорилось выше создать пароль для postgre:

Сливаем данные с node1(мастера):
Под этим пользователем переливаем данные с мастера:

Попросят пароль от пользователя постгрес на 1 сервере(node1). Введем его.

Создадим конфиг рекавери на:

Вставим строки в пустой файл:

Также в recovery.conf можно дописать:

… если вы хотите реплику, отстающую от мастера на заданное количество времени.
Это позволит быстро восстановить данные в случае выполненного случайно drop database.

Правим конфиг подлкючений на 2-й ноде

Настраиваем конфиг

Приводи к такому виду как на первом, только меняем listen_addresses

Запускаем PostgreSQL:

Проверяем висит ли Postgresql на порте

4.Проверка репликации

На мастере говорим:

На реплике(node2)

5.Переключаем реплику в режим мастера

Остановим мастер. Допустим, что-то случилось.

В логе увидим:

При этом в каталоге /var/lib/postgresql/9.5/main файл recovery.conf автоматически будет переименован в recovery.done.
Легко проверить, что в бывшую реплику теперь можно писать. Конечно, если только вы не использовали синхронную репликацию с одной-единственной репликой.
Интересно, что хотя реплику и можно промоутнуть до мастера без перезапуска PostgreSQL, на практике вы, вероятно, все же захотите его перезапустить по следующей причине. Дело в том, что приложение, которое ранее подключилось к этой реплике, так и будет использовать ее в качестве реплики даже после промоута, хотя операции чтения можно было бы размазать по остальным репликам в кластере. Перезапустив PostgreSQL, вы порвете все сетевые соединения, а значит приложению придется подключиться заново, проверить, подключился ли он к мастеру или реплике (запрос SELECT pg_is_in_recovery(); вернет false на мастере и true на репликах), и использовать сетевое соединение соответствующим образом.

6.Переключение на новый мастер оставшихся реплик и восстановление упавшего мастера до реплики.

Переключение остальных реплик на новый мастер, а также восстановление бывшего мастера в качестве реплики происходит одинаково.
Чтобы было чуть меньше путаницы с новым мастером, старым мастером, старой репликой и новой репликой, условимся, что сервера мы называем в соответствии с их текущими ролями. То есть, мастером мы называем новый мастер, бывший репликой до фейловера, а репликой — тот, второй сервер.
В простом и не совсем правильном варианте нужно отредактировать, или создать, если его еще нет, файл /var/lib/postgresql/9.5/main/recovery.conf, указав в нем правильный IP мастера, и сделать sudo service postgresql restart (простой reload не прокатит). Кто-то для того, чтобы не править конфиги и не останавливать СУБД, использует схему с балансировщиком и DNS, но я лично так никогда не делал. В любом случае, этот способ неправильный. Для того, чтобы все хорошо работало во всяких хитрых граничных случаях, реплику следует остановить, сделать pg_rewind, затем запустить реплику.
Утилита pg_rewind находит точку в WAL, начиная с которой WAL мастера и WAL реплики начинают расходиться. Затем она «перематывает» (отсюда и название) WAL реплики на эту точку и накатывает недостающую историю с мастера. Таким образом, реплика и мастер всегда приходят к консистентному состоянию. Плюс к этому pg_rewind синхронизирует файлы мастера и реплики намного быстрее, чем pg_basebackup или rsync.
Если вы считаете, что pg_rewind не требуется при использовании синхронной репликации, вот пример маловероятной, но теоретически возможной ситуации. У вас много серверов с PostgreSQL. Сервера в кластере умирают сравнительно часто, поэтому вы решили автоматизировать фейловер. Умирает мастер, запускается фейловер. Среди реплик находится та, что имеет наиболее длинный WAL, на ней делается pg_ctl promote. В этот момент с очень большой задержкой (скажем, 5 секунд — были какие-то сетевые проблемы) на другую реплику прилетает пакет от уже мертвого мастера, и WAL этой реплики становится длиннее WAL нового мастера. Вы не сможете подключить эту реплику к новому мастеру, все сломалось. Если вы хотите, чтобы фейловер работал в том числе и при таких странных граничных случаях, используйте pg_rewind.
Итак, на реплике говорим:

Типичный вывод:

Перемещаем и правим recovery.conf:

Проверяем IP мастера и наличие строчки:

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

Значит PostgreSQL работает в качестве реплики.
Если вдруг видим что-то вроде:

… значит реплика слишком отстала от мастера, и нужно перенести файлы с мастера при помощи pg_basebackup, как было описано в начале этой статьи.

7.Добавление дополнительного слейва postgresql

Допустим вам понадобилось добавить еще один slave, пусть это будет pg3.domain.local c ip адресом 10.4.1.163. Это всё делается очень просто.

  1. Устанавливаем postgresql там же образом как и 1-ый слейв, также редактируем postgres.conf

Правим конфиг подлкючений на 3-й ноде

Сливаем данные с node1(мастера):
Под этим пользователем переливаем данные с мастера:

Попросят пароль от пользователя постгрес на 1 сервере(node1). Введем его.

Создадим конфиг рекавери на:

Вставим строки в пустой файл:

Не забываем добавить на ТЕКУЩЕМ МАСТЕР сервере новую реплику в разрешенные подключения(ДОБАВИМ СТРОКИ НА МАСТЕР СЕРВЕРЕ, А ЗАОДНО И НАДРУГИХ РЕКПЛИКАХ, НА СЛУЧАЙ ПЕРЕХОДА ИХ В РЕЖИМ МАСТЕРА):

8.Настройка балансировки через PGPOOL2

Если у вас несколько нод, то вы захотите настроить балансировку на них, чтобы подключение шло через одну точку.
Для этого мы будем использовать pgpool2.
Установка. Будем ставить из исходника, но для начала установим и удалим пакет — усвоил это урок из установки Nginx из исходников

Качаем исходники

cd /tmp
wget https://www.pgpool.net/download.php?f=pgpool-II-3.5.4.tar.gz
tar -xvf download.php?f=pgpool-II-3.5.4.tar.gz
cd download.php?f=pgpool-II-3.5.4

Ставим пакеты для сборки

apt-get install libpq-dev make checkinstall -y

Конфигурируем и устанавливаем


Устанавливаем в систему


Переходим в каталог с файлами
cd /usr/local/etc

Настройка. Отредактируем файл pgpool.conf

Удалим все и вставим след конфиг

Заметьте порт у нас 5432, а сам постгрес крутится на 5433, т.е. pgpool2 можно ставить на нады с postgresql.
Отредактим файл подключений pool_hba.conf

Отредактим файл c паролями для подключениями к pgpool2

Туда надо вставить пользователя и его md5 пароль

ВАЖНО!!! Пароль получаем из postgresql

И получим пароль. Вставим его в файл. Применяем права на каталог pgpool и рестартимся.

8.Заключение

Всё мы получили репликацию и балансировку.

Автор:human

Установка базы данных Tarantool

tarantool bdБаза данных тарантул — это базы данных наших отечетвенных разработчиков, информации в сети по ним немного, вот что пишет сам автор базы данных Tarantool о своём «детище» на хабре:

«На сайте мы пишем про себя, что это что-то вроде микса между Node.JS и Redis. Основная идея в том, чтобы быстро работать с большими объёмами данных в памяти, при этом делать что-то более нетривиальное чем key/value или те структуры данных, которые предоставляет Редис. Идея в том, что у вас десятки, сотни гигабайт живых данных, и у вас есть возможность делать с ними что-то действительно сложное. Антикэш, считать какие-то хитрые корреляции, держать состояние онлайн-игры, и в реалтайме высчитывать рейтинги игроков и т.п.»

https://habrahabr.ru/company/mailru/blog/252065/

Установка БД Tarantool  в Ubuntu

Автор:human

Перенос базы данных mysql на другой диск

Перенос базы данных mysql на другой диск

Например, Вам понадобилось хранить mysql базы на другом диске. У меня например,в переменных хранится onlyoffice и базы данных.
Предположим диск для хранения БД уже подключен и смонтирован в каталог — /var/database. Операции проводились на ubuntu server 14.04.4. Mysql 5.5Теперь перейдем к настройке.

Останавливаем службу mysql

Далее копируем каталог с существующими БД на новый диск

Теперь открываем файл — /etc/mysql/my.cnf

В нем меняем значение параметра — datadir , оно должно соответствовать пути к новому диску.

Далее меняем значения AppArmor

Открываем файл — /etc/apparmor.d/usr.sbin.mysqld

Меняем все значения — /var/lib/mysql на /var/database/mysql

Перезапускаем службу AppArmor

Запускаем Mysql

Готово! Теперь БД будет храниться на новом диске.