Установка клиента

# macOS
brew install minio/stable/mc

# Windows
Download https://dl.min.io/client/mc/release/windows-amd64/mc.exe

# Linux
wget https://dl.min.io/client/mc/release/linux-amd64/mc
chmod +x mc

Авторизация клиента

ALIAS - имя подключения
S3-ENDPOINT - URL вашего minio сервера
ACCESS-KEY - ключ доступа
SECRET-KEY - пароль.

mc alias set <ALIAS> <S3-ENDPOINT> <ACCESS-KEY> <SECRET-KEY>

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

mc admin user add <ALIAS>

Создание бакета

mc mb <ALIAS>/<BUCKET_NAME>

Добавление пермишшенов

Права доступа добавляются через концепцию policy. Для примера добавим права администрирования объектов для определенного бакета, а после - выдадим эти права нашему пользователю.

Создаем локальный файл bucket-policy.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "s3:*"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::<BACKET_NAME>/*"
      ],
      "Sid": ""
    }
  ]
}

Или еще пример, который дает право на запись определенному пользователю только в его бакет. Но, при этом, он может видеть все остальное:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "s3:PutBucketPolicy",
        "s3:GetBucketPolicy",
        "s3:DeleteBucketPolicy",
        "s3:ListAllMyBuckets",
        "s3:ListBucket"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::user2bucket"
      ],
      "Sid": ""
    },
    {
      "Action": [
        "s3:AbortMultipartUpload",
        "s3:DeleteObject",
        "s3:GetObject",
        "s3:ListMultipartUploadParts",
        "s3:PutObject"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::user2bucket/*"
      ],
      "Sid": ""
    }
  ]
}

В данном файле мы описываем права доступа для бакета <BACKET_NAME>.

После этого нам потребуется выгрузить пермиссии на сервер и сохранить под именем <POLICY_NAME>:

mc admin policy add <ALIAS> <POLICY_NAME> ./bucket-policy.json

Далее нам нужно применить наш policy к ранее созданному пользователю:

mc admin policy set <ALIAS> <POLICY_NAME> user=<USER_NAME>

Выдать пользователю RO на базу

-- Создаем группу для RO
CREATE ROLE readonly;

-- Даём доступ к существующим таблицам
GRANT USAGE ON SCHEMA public TO readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly;

-- Даём доступ к будущим таблицам
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO readonly;

-- Создаем пользователя с правами RO
CREATE USER пользователь WITH PASSWORD 'пароль';
GRANT readonly TO пользователь;

-- На конкретную базу
GRANT CONNECT ON DATABASE ИМЯ_БД TO пользователь;
GRANT USAGE ON SCHEMA public TO пользователь;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO пользователь;
GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO пользователь;

Дампим БД с исключением таблиц и восстанавливаем на другом Хосте

Сначала склонируем:

pg_dump \
--clean \
--encoding=utf8 \
--format=directory \
--jobs=5 \
--verbose \
--compress=5 \
--exclude-table=table_num_1_to_exclude \
--exclude-table=table_num_1_to_exclude \
--file=DIR_NAME \
--dbname=DB_NAME \
--host=HOST \
--port=PORT \
--username=USERNAME \
--password

Потом архивируем

tar -cvf ARCHIVE_NAME.tar.gz DIR_NAME/
rm -rf DIR_NAME/

Потом копируем на удаленный хост и разархивируем

tar -xvf ARCHIVE_NAME.tar.gz
rm ARCHIVE_NAME.tar.gz

И восстанавливаем

pg_restore \
--dbname=IMPORT_DAB_NAME \
--format=directory \
--jobs=5 \
--verbose \
--host=HOST \
--port=PORT \
--username=USERNAME \
--password \
DIR_NAME

Смотрим отставание реплик в кластере PostgreSQL + Patroni

--получить лаг в реплика
select 
    r.client_addr,
    r.usename,
    r.application_name,
    r.state,
    r.sync_state,
    --сколько сгенерировано, но не отправлено
    --если > 0, то говорит о сетевой проблеме => запусти nicstat
    (pg_wal_lsn_diff(pg_current_wal_lsn(), r.sent_lsn) / 1024)::int as pending,

    --сколько отправлено, но не записано
    --если много, то проблема с диском -> запусти io top
    (pg_wal_lsn_diff(r.sent_lsn,  r.write_lsn) / 1024)::int as write,

    --записано, но не было выпущено (еще  в ОЗУ) не закоммичено
    --если много => trouble at HDDs => запусти IO STAT || io top
    (pg_wal_lsn_diff(r.write_lsn, r.flush_lsn) / 1024)::int as flush,

    --данные засинканы, но не воспроизведены репликой
    --если >0 => диски или цпу => запусти IO STAT || io top
    (pg_wal_lsn_diff(r.flush_lsn, r.replay_lsn) / 1024)::int as replay,
    --всего
    ((pg_wal_lsn_diff(pg_current_wal_lsn(), r.replay_lsn)) / 1024)::int as total_lag
from pg_catalog.pg_stat_replication as r

1. Подготовка

1.1 Сначала ставим 10 PostgreSQL

Версии на серверах должны быть одинаковые.

sudo apt-get update
sudo apt-get -y upgrade

wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -

echo "deb http://apt.postgresql.org/pub/repos/apt/ $(lsb_release -cs)-pgdg main" \
| sudo tee /etc/apt/sources.list.d/postgresql-pgdg.list > /dev/null

sudo apt-get update

sudo apt-get install postgresql-10

dpkg -l | grep postgresql

1.2 Настраиваем брандмауэр

При использовании брандмауэра, необходимо открыть TCP-порт 5432 — он используется сервером postgre.

а) Firewalld:

firewall-cmd --permanent --add-port=5432/tcp
firewall-cmd --reload

б) Iptables:

iptables -A INPUT -p tcp --dport 5432 -j ACCEPT

в) UFW:

ufw allow 5432/tcp

1.3 Отключаем SELinux

Если активирована система безопасности SELinux (по умолчанию в системах Red Hat / CentOS / Fedora), отключаем ее:

setenforce 0
sed -i 's/^SELINUX=.*/SELINUX=disabled/g' /etc/selinux/config

Если необходимо, чтобы SELinux работал, настраиваем его.

2. Настройки на Master

Будем настраивать серверы с IP-адресами 10.14.0.143 (первичный или master) и 10.14.0.85 (вторичный или slave).

Переходим на сервер, с которого будем реплицировать данные (мастер) и выполняем следующие действия.

2.1 Создаем пользователя в PostgreSQL

Входим в систему под пользователем postgres:

sudo su
su postgres

Создаем нового пользователя для репликации:

createuser --replication -P repluser

* система запросит пароль — его нужно придумать и ввести дважды. В данном примере мы создаем пользователя repluser.

Выходим из оболочки пользователя postgres:

exit

2.2 Настраиваем postgresql

Смотрим расположение конфигурационного файла postgresql.conf командой:

su -u postgres -c "psql -c 'SHOW config_file;'"

В моем случае система вернула строку:

/etc/postgresql/10/main/postgresql.conf

* конфигурационный файл находится по пути /etc/postgresql/10/main/postgresql.conf.

Открываем конфигурационный файл postgresql.conf.

nano /etc/postgresql/10/main/postgresql.conf

Редактируем следующие параметры:

listen_addresses = 'localhost, 10.14.0.143'
wal_level = replica
max_wal_senders = 2
max_replication_slots = 2
hot_standby = on
hot_standby_feedback = on

Открываем конфигурационный файл pg_hba.conf — он находитсяч в том же каталоге, что и файл postgresql.conf:

nano /etc/postgresql/10/main/pg_hba.conf

Добавляем следующие строки:

host replication repluser 127.0.0.1/32 md5
host replication repluser 10.14.0.143/32 md5
host replication repluser 10.14.0.85/32 md5

* данной настройкой мы разрешаем подключение к базе данных replication пользователю repluser с локального сервера (localhost и 10.14.0.143) и сервера 10.14.0.85.

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

systemctl restart postgresql

• обратите внимание, что название для сервиса в системах Linux может различаться.
  
  

3. Настройки на Slave

3.1 Подготавливаемся к репликации

Смотрим путь до конфигурационного файла postgresql:

sudo su
su -u postgres -c "psql -c 'SHOW data_directory;'" 

В моем случае путь был:

/var/lib/postgresql/10/main

Также смотрим путь до конфигурационного файла postgresql.conf (нам это понадобиться ниже):

su -u postgres -c "psql -c 'SHOW config_file;'"

Останавливаем сервис postgresql:

systemctl stop postgresql

На всякий случай, создаем архив базы:

tar -czvf /tmp/data_pgsql.tar.gz /var/lib/postgresql/10/main

* в данном примере мы сохраним все содержимое каталога /var/lib/pgsql/9.6/data в виде архива /tmp/data_pgsql.tar.gz.

Удаляем содержимое каталога с данными:

rm -rf /var/lib/postgresql/10/main/*

3.2 Реплицируем данные с Master сервера

а) Если у нас postgresql 9:

su -u postgres -с "pg_basebackup \
-h 10.14.0.143 \
-U repluser \
-D /var/lib/pgsql/9.6/data \
--xlog-method=stream \
--write-recovery-conf"

• где 10.14.0.143 — IP-адрес мастера
• /var/lib/pgsql/9.6/data — путь до каталога с данными.

б) Если у нас postgresql 10:

# Входим в screen
screen -S recovery
sudo su

pg_basebackup \
--host=10.14.0.143 \
--username=repluser \
--pgdata=/var/lib/postgresql/10/main \
--progress \
--checkpoint=fast \
--wal-method=stream \
--write-recovery-conf \
&& chown -R postgres:postgres /var/lib/postgresql/10/main \
&& service postgresql start

# Выход из Screen Ctrl+a и d
# Просмотр всех сеансов screen -ls
# Подключится обратно screen -r recovery

• где 10.14.0.143 — IP-адрес мастера
• /var/lib/postgresql/10/main — путь до каталога с данными.

После ввода команды система запросит пароль для созданной ранее учетной записи repluser — вводим его. Начнется процесс клонирования данных.

А еще, желательно, почитать о том, что такое pg_basebackup

3.3 Настраиваем конфиг Slave сервера после клонирования данных

Ввиду того, что утилита pg_basebackup (которой мы пользовались выше) клонирует БД полностью, в том числе и конфиги, то не повторяйте мою ошибку. Только после окончания миграции данных из пункта 2.2 вы открываете конфигурационный файл postgresql.conf на Slave:

nano /etc/postgresql/10/main/postgresql.conf

Если это сделать во время миграции, старый конфиг, который вы изменили, затрется тем, что восстановится с Master и репликации у вас не будет. А будут только данные, сбэкапленные с Мастера. Идем дальше.

И редактируем следующие параметры:

listen_addresses = 'localhost, 10.14.0.85'

• где 10.14.0.85 — IP-адрес нашего вторичного сервера (Slave).

Снова запускаем сервис postgresql:

systemctl start postgresql

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

4.1 Посмотреть статус

Статус работы репликации можно посмотреть следующими командами.

На Master:

select * from pg_stat_replication;

На Slave:

select * from pg_stat_wal_receiver;

4.2 Создать тестовую базу

На мастере заходим в командную оболочку PostgreSQL:

su -u postgres -c "psql"

Создаем новую базу данных:

=# CREATE DATABASE repltest ENCODING='UTF8';

Теперь на Slave сервере смотрим список баз:

su -u postgres -c "psql"

=# \l

Мы должны увидеть среди баз ту, которую создали на первичном сервере:

   Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access
 ...
 repltest  | postgres | UTF8     | ru_RU.UTF-8 | ru_RU.UTF-8 | 
 ...

sudo -u postgres /usr/lib/postgresql/10/bin/pg_ctl promote -D /var/lib/postgresql/10/main

sudo -u postgres /usr/lib/postgresql/9.5/bin/pg_rewind \
  -D /var/lib/postgresql/9.5/main/ \
  --source-server="host=10.0.3.223 port=5432 user=postgres password=??"

sudo mv /var/lib/postgresql/9.5/main/recovery.done \
  /var/lib/postgresql/9.5/main/recovery.conf
sudo vim /var/lib/postgresql/9.5/main/recovery.conf

recovery_target_timeline = 'latest'

LOG:  database system is ready to accept read only connections

ERROR: requested WAL segment 0000000200000005 has already been removed

sudo locale-gen ru_RU.UTF-8

Вот сам скрипт. Тут, думаю, все и так понятно.

#!/bin/bash

# Создание пользователя для подключения к хостам. Включая доступ по ssh ключам.
# Пароль для пользователя генерится рандомным образом и состоит из 20 символов
# На удаленной машине залогинится под рутом и запустить вот так:
# curl -s https://devops.org.ru/cu.sh | bash /dev/stdin

# Переменные
USERNAME="devops"
PASSWORD=`tr -cd '[:alnum:]' < /dev/urandom | fold -w20 | head -n1`
HOSTNAME=`hostname -I | cut -d' ' -f1`
# Публичный ключ для файла authorized_keys сгенерированный с помощью linux машины управления
LINUXKEY="ssh-rsa key"
# Публичный ключ для файла authorized_keys сгенерированный с помощью putty
PUTTYKEY="ssh-rsa key"
# Проверяем, под рутом ли запущен скрипт.
if [ "$(whoami)" != 'root' ]; then
echo "Для запуска скрипта вы должны войти под пользователем ROOT! Выходим..."
exit 1;
fi

# Проверяем пользователя, есть ли такой в системе.
if id -u $USERNAME >/dev/null 2>&1;
then
    echo "Пользователь $USERNAME уже есть в системе. Выходим"
    exit 1;
fi

# Создаем пользователя
useradd -m -s /bin/bash "$USERNAME"
echo -e "$PASSWORD\n$PASSWORD" | passwd "$USERNAME"

# Прописываем пользователю SUDO без запроса пароля
echo -e "$USERNAME     ALL=(ALL)    NOPASSWD: ALL" > /etc/sudoers.d/$USERNAME

# Создаем директорию .ssh и файл авторизации по ключам
mkdir -p /home/$USERNAME/.ssh
echo -e $LINUXKEY >> /home/$USERNAME/.ssh/authorized_keys
echo -e $PUTTYKEY >> /home/$USERNAME/.ssh/authorized_keys

# Исправляем прова доступа
chown -R $USERNAME:$USERNAME /home/$USERNAME/.ssh/authorized_keys
chmod -R 0600 /home/$USERNAME/.ssh/authorized_keys

echo ""
echo "Пользователь $USERNAME c паролем: $PASSWORD создан на хосте $HOSTNAME"

1. Добавляем место для виртуалки, через веб-интерфейс ProxMox (Resize disk), либо через консоль гипервизора:
   

   qm resize <vmid> <disk> <size>
   
   Пример:
   qm resize 100 virtio0 +5G ### добавили 5Гб для vm 100 к диску virtio0

2. Заходим на vm
3. fdisk -l должен показать полный размер диска и созданные партиции.
4. Расширяем нужную партицию через удобный вам инструмент, например cfdisk:
   

   cfdisk /dev/sda

   Выбираем партицию -> жмем Resize -> пишем размер диска (по умолчанию все доступное место) -> Write

5. Расширяем Physical volume:

   pvresize /dev/sda ### расширяем
   pvdisplay ### проверяем что размер изменился

6. Расширяем Logical volume:

   vgdisplay ### проверяем что в Volume group есть место "Free PE / Size"
   lvextend -r -l +100%FREE /dev/VolumeGroup/lv ### Расширяем Logical volume на все доступное пространство
   resize2fs /dev/VolumeGroup/lv ### фиксируем изменения
   xfs_growfs /dev/VolumeGroup/lv ### Данную команду используем на CentOS вместо resize2fs

   
   Profit...
   
   Не забываем про 

   lsblk
   fdisk -l
   df -h

Увеличение диска без LVM

sudo fdisk /dev/sda
p
d
выбрать диск
n
выбрать раздел
enter
enter
удалить сигнатуру y
p - проверяем диск
w
sudo resize2fs /dev/sda1

Расширяем LVM другим диском

1. Добавляем диск в ВМ
2. fdisk -l - находим добавленный диск (например /dev/sdf)
3. Делаем fdisk /dev/sdf
p
n
enter
enter
enter
enter
p
t
8e
p
w
pvcreate /dev/sdf1
vgs и выбираем имя vgs
vgextend VGS_NAME /dev/sdN
df -h и выбираем LVM который нужно расширить
lvextend -l +100%FREE /dev/mapper/db--vkok--vg-pgdata
resize2fs /dev/mapper/db--vkok--vg-pgdata
Ждем. Проверячем через df -h