my_postresql
6 subscribers
3 photos
3 videos
12 files
111 links
Download Telegram
### Подготовка окружения и основные параметры конфигурации для стабильной работы системы

1. Создание пользователей и ролей:
   CREATE ROLE patroni_user WITH LOGIN PASSWORD 'example_password';
GRANT ALL PRIVILEGES ON DATABASE my_db TO patroni_user;


2. Настройка сетевого взаимодействия:
Откройте порты PostgreSQL и Patroni в брандмауэре.

3. Оптимизация параметров PostgreSQL:
Отредактируйте файл postgresql.conf:
   max_connections = 500
shared_buffers = 1GB
effective_cache_size = 3GB
work_mem = 256MB
maintenance_work_mem = 512MB
autovacuum = on


---

## Администрирование

### Основы администрирования PostgreSQL в Patroni кластере

#### Управление ролями экземпляров

1. Создание роли:
   CREATE ROLE new_role WITH LOGIN PASSWORD 'password';


2. Предоставление привилегий:
   GRANT USAGE ON SCHEMA public TO new_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO new_role;


#### Выполнение задач по поддержке баз данных и диагностике

1. Резервное копирование:
   pg_dump -U postgres -h localhost -p 5432 my_db > backup.sql


2. Диагностика:
   EXPLAIN ANALYZE SELECT * FROM my_table WHERE id = 123;


---

## Конфигурация, режимы репликации, поддержка слотов логической репликации

### Углубленное изучение настройки репликации в PostgreSQL

#### Логическая репликация

1. Создание слота репликации:
   SELECT * FROM pg_create_logical_replication_slot('my_slot', 'test_decoding');


2. Подключение к слоту:
   START REPLICATION SLOT my_slot LOGICAL my_lsn;


#### Создание и поддержка слотов репликации для повышения отказоустойчивости

1. Мониторинг слотов:
   SELECT * FROM pg_replication_slots;


2. Удаление слота:
   SELECT pg_drop_replication_slot('my_slot');


---

## Конвертация экземпляра в Patroni кластер

### Перевод существующего экземпляра PostgreSQL в кластер Patroni

1. Остановите PostgreSQL:
   systemctl stop postgresql


2. Создайте конфигурационный файл Patroni:
   scope: my_cluster
name: node1
restapi:
listen: 127.0.0.1:8008
connect_address: 127.0.0.1:8008
bootstrap:
dcs:
ttl: 30
loop_wait: 10
retry_timeout: 10
maximum_lag_on_failover: 1048576
postgresql:
use_pg_rewind: true
parameters:
wal_level: hot_standby
hot_standby: "on"
max_connections: 100
max_worker_processes: 8
shared_buffers: 128MB
effective_cache_size: 384MB
maintenance_work_mem: 64MB
checkpoint_completion_target: 0.9
wal_buffers: 16MB
default_statistics_target: 100
random_page_cost: 4.0
effective_io_concurrency: 200
work_mem: 6553kB
min_wal_size: 1GB
max_wal_size: 2GB
postgresql:
listen: 127.0.0.1:5432
connect_address: 127.0.0.1:5432
data_dir: /data/pgsql/data
bin_dir: /usr/lib/postgresql/13/bin
config_dir: /data/pgsql/config
pgpass: /tmp/passfile
authentication:
superuser:
username: postgres
password: example_password
replication:
username: replicator
password: example_replication_password
parameters:
wal_level: replica
max_wal_senders: 10
wal_keep_segments: 32
hot_standby: on
archive_mode: on
archive_command: 'cp %p /archivedir/%f'
restore_command: 'cp /archivedir/%f %p'
tags:
nofailover: false
noloadbalance: false
clonefrom: false
nosync: false


3. Запустите Patroni:
   patroni /path/to/your/config.yml


---

## Обновление мажорной версии PostgreSQL

### Безопасные методы обновления PostgreSQL до новой мажорной версии с минимизацией простоев и рисков

1. Резервное копирование:
   pg_dumpall -U postgres -h localhost -p 5432 > backup.sql


2. Остановите Patroni:
   patroni stop


3. Обновите PostgreSQL:
   apt-get update && apt-get upgrade postgresql-server


4. Запустите Patroni:
   patroni start


---
## Резервный кластер, несколько ЦОДов

### Настройка резервных кластеров PostgreSQL для нескольких дата-центров

1. Создание нового кластера:
   patroni create-cluster secondary_cluster


2. Настройка репликации:
   ALTER SYSTEM SET wal_level = 'replica';
ALTER SYSTEM SET synchronous_commit = 'remote_write';


3. Синхронизация данных:
   pg_basebackup -h primary_host -U replicator -D /secondary_data_dir


---

Эти шаги помогут вам эффективно управлять PostgreSQL и Patroni кластерами, обеспечивая высокую доступность и надежность ваших баз данных.
ФОРС УЦ
Forwarded from IT Portal
This media is not supported in your browser
VIEW IN TELEGRAM
Очередной годный сайт для прокачки навыков SQL-запросов

На платформе вам предстоит решать задачи, используя базу данных больницы. Задачи разделены по уровням сложности, начиная с простых запросов с SELECT и постепенно переходя к более сложным

Есть подсказки и возможность получить готовый запрос, если застряли 👍

@PortalToIT
Please open Telegram to view this post
VIEW IN TELEGRAM
Ошибка "server closed the connection unexpectedly" означает, что сервер неожиданно закрыл соединение до обработки запроса. Это может происходить по разным причинам:

## Основные причины возникновения такой ошибки:

1. Некорректная остановка сервера
Сервер PostgreSQL мог завершиться аварийно или некорректно остановлен вручную.

2. Проблемы с ресурсом
Недостаточность памяти, CPU или дискового пространства может вызвать принудительное завершение работы сервера.

3. Конфликт с конфигурационными параметрами
Некорректные значения в файле конфигурации (например, неправильные лимиты ресурсов) могут приводить к подобным проблемам.

4. Кэширование или временная проблема сети
Иногда такая ошибка может возникать временно из-за сбоев сети или кэшированных DNS-запросов.

5. Повреждение базы данных
Поврежденные таблицы или индексы могут заставить сервер закрыть сеанс неожиданным образом.

## Как решать данную проблему:

### 1. Проверяем статус сервера:

sudo systemctl status postgresql


Или проверяем процесс вручную:

ps aux | grep postgres


Если сервер остановлен, пробуем снова его запустить:

sudo systemctl start postgresql


### 2. Проверяем журнал ошибок:

Посмотреть логи можно командой:

cat /var/log/postgresql/postgresql-*.log


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

journalctl -xe


### 3. Проверяем использование ресурсов:

Просмотрим статистику использования оперативной памяти и диска:

free -m
df -h
top


### 4. Анализируем целостность баз данных:

Иногда повреждение структуры БД может вести к таким симптомам. Рекомендуется запустить проверку целостности:

sudo su - postgres
psql -c "CHECKPOINT;"
vacuumdb -zA --all


Также можно воспользоваться инструментом восстановления pg_dump для полного бекапа и последующего восстановления.

### 5. Временные меры (перезагрузка):

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

sudo reboot


### Итоговые выводы:

Если вышеуказанные методы не помогают, то следует обратиться к подробному исследованию логов и документации PostgreSQL относительно известных проблем с такими симптомами. Чаще всего подобные ситуации связаны с ресурсами или повреждением таблиц.
# Настройка pgBackRest на мастер-сервере PostgreSQL с Patroni

## 1. Подготовка сервера

### 1.1. Установка pgBackRest
sudo apt install -y pgbackrest


### 1.2. Создание пользователя для бэкапов
sudo -u postgres psql -c "CREATE ROLE backupuser WITH LOGIN PASSWORD 'securepassword' SUPERUSER;"


## 2. Конфигурация pgBackRest

### 2.1. Создание конфигурационного файла
sudo tee /etc/pgbackrest.conf << EOF
[global]
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
log-level-console=info
log-level-file=debug
archive-async=y
spool-path=/var/spool/pgbackrest
process-max=4

[postgres-cluster] # Должно соответствовать scope в Patroni
pg1-path=/var/lib/postgresql/15/main
pg1-port=5432
pg1-user=backupuser
pg1-host=localhost
pg1-host-user=postgres
EOF


### 2.2. Настройка прав доступа
sudo mkdir -p /var/lib/pgbackrest /var/spool/pgbackrest
sudo chown postgres:postgres /var/lib/pgbackrest /var/spool/pgbackrest
sudo chmod 750 /var/lib/pgbackrest /var/spool/pgbackrest


## 3. Интеграция с Patroni

### 3.1. Обновление конфигурации Patroni
Добавьте в /etc/patroni.yml в секцию bootstrap:

bootstrap:
dcs:
postgresql:
parameters:
archive_mode: "on"
archive_command: "pgbackrest --stanza=postgres-cluster archive-push %p"
archive_timeout: "300"


### 3.2. Перезапуск Patroni
sudo systemctl restart patroni


## 4. Инициализация pgBackRest

### 4.1. Создание stanza
sudo -u postgres pgbackrest --stanza=postgres-cluster stanza-create


### 4.2. Проверка конфигурации
sudo -u postgres pgbackrest --stanza=postgres-cluster check


## 5. Настройка бэкапов

### 5.1. Первый полный бэкап
sudo -u postgres pgbackrest --stanza=postgres-cluster --type=full backup


### 5.2. Настройка cron для регулярных бэкапов
sudo tee /etc/cron.d/pgbackrest << EOF
30 0 * * * postgres pgbackrest --stanza=postgres-cluster --type=diff backup
30 0 * * 0 postgres pgbackrest --stanza=postgres-cluster --type=full backup
EOF


## 6. Настройка WAL-G (альтернатива)

### 6.1. Установка WAL-G
wget https://github.com/wal-g/wal-g/releases/download/v2.0.1/wal-g-pg-ubuntu-20.04-amd64.tar.gz
sudo tar -xvzf wal-g-pg-ubuntu-20.04-amd64.tar.gz -C /usr/local/bin
sudo chmod +x /usr/local/bin/wal-g


### 6.2. Настройка окружения
sudo tee /etc/wal-g/env.sh << EOF
export WALG_S3_PREFIX=s3://your-bucket-name/postgres-cluster
export AWS_ACCESS_KEY_ID=your_access_key
export AWS_SECRET_ACCESS_KEY=your_secret_key
export AWS_REGION=your-region
export WALG_COMPRESSION_METHOD=lz4
export WALG_DISK_RATE_LIMIT=41943040
export WALG_NETWORK_RATE_LIMIT=10485760
EOF

sudo chown postgres:postgres /etc/wal-g/env.sh
sudo chmod 640 /etc/wal-g/env.sh


### 6.3. Обновление Patroni для WAL-G
bootstrap:
dcs:
postgresql:
parameters:
archive_mode: "on"
archive_command: ". /etc/wal-g/env.sh; wal-g wal-push %p"


## 7. Восстановление из бэкапа

### Для pgBackRest:
sudo systemctl stop patroni
sudo -u postgres pgbackrest --stanza=postgres-cluster --type=time --target="2023-01-01 12:00:00" restore
sudo systemctl start patroni


### Для WAL-G:
wal-g backup-fetch /var/lib/postgresql/15/main LATEST


## 8. Мониторинг бэкапов

### Для pgBackRest:
sudo -u postgres pgbackrest info


### Для WAL-G:
wal-g backup-list


## Важные замечания:
1. Для S3 хранилища потребуется дополнительная настройка доступа
2. Регулярно проверяйте целостность бэкапов
3. Храните учетные данные бэкапов в безопасном месте
4. Настройте мониторинг процесса бэкапирования
Ошибка возникает потому что вы используете старую версию etcdctl (v2), а флаг --write-out доступен только в v3 API. Давайте правильно проверим кластер etcd:

## Способ 1: С использованием ETCDCTL_API=3

ETCDCTL_API=3 etcdctl \
--endpoints="http://192.168.31.168:2379,http://192.168.31.122:2379,http://192.168.31.215:2379" \
--write-out=table \
endpoint status


## Способ 2: Альтернативные команды для проверки

### Проверка списка членов кластера:
ETCDCTL_API=3 etcdctl \
--endpoints="http://192.168.31.168:2379" \
member list \
--write-out=table


### Проверка здоровья кластера:
ETCDCTL_API=3 etcdctl \
--endpoints="http://192.168.31.168:2379,http://192.168.31.122:2379,http://192.168.31.215:2379" \
endpoint health


### Тест записи/чтения:
ETCDCTL_API=3 etcdctl \
--endpoints="http://192.168.31.168:2379" \
put test_key "test_value"

ETCDCTL_API=3 etcdctl \
--endpoints="http://192.168.31.168:2379" \
get test_key


## Способ 3: Постоянное установление API v3

Чтобы не указывать ETCDCTL_API=3 каждый раз, добавьте в .bashrc:
echo "export ETCDCTL_API=3" >> ~/.bashrc
source ~/.bashrc


## Если команды не работают:

1. Убедитесь, что etcd установлен и работает:
sudo systemctl status etcd


2. Проверьте версию etcdctl:
etcdctl version


3. Для etcd v2 используйте:
etcdctl \
--peers="http://192.168.31.168:2379,http://192.168.31.122:2379,http://192.168.31.215:2379" \
cluster-health


Пример корректного вывода для v3 API:
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| http://192.168.31.168:2379 | 8e9e05c52164694d | 3.3.25 | 1.5 MB | true | false | 2 | 1234 | 1234 | |
| http://192.168.31.122:2379 | 1bf1a41159b6f852 | 3.3.25 | 1.4 MB | false | false | 2 | 1234 | 1234 | |
| http://192.168.31.215:2379 | 97e476f8d5e1f3e4 | 3.3.25 | 1.4 MB | false | false | 2 | 1234 | 1234 | |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
Команда sudo -u postgres pgbackrest --stanza=postgres-cluster stanza-create должна выполняться на всех серверах с PostgreSQL, которые являются частью вашего кластера (в вашем случае это postgres1, postgres2, postgres3), но с некоторыми нюансами:

---

### Где именно создавать stanza:
1. Первичное создание:
- Выполняется только на текущем master-сервере PostgreSQL
- Определить мастера можно командой:
     sudo -u postgres psql -c "SELECT pg_is_in_recovery();"

(f = master, t = replica)

2. На репликах:
- После создания на мастере stanza автоматически синхронизируется с репликами
- Вручную запускать на репликах не нужно (но можно выполнить проверку):
     sudo -u postgres pgbackrest --stanza=postgres-cluster check


---

### Почему только на мастере:
- stanza-create инициализирует структуру для хранения WAL-файлов и бэкапов
- Реплики получают WAL-файлы через механизм репликации PostgreSQL
- Повторное выполнение на репликах может вызвать конфликты

---

### Полный процесс настройки:

1. На master-сервере (например, postgres1):
   # Создание stanza
sudo -u postgres pgbackrest --stanza=postgres-cluster stanza-create

# Первый бэкап
sudo -u postgres pgbackrest --stanza=postgres-cluster --type=full backup


2. На всех серверах (проверка конфигурации):
   sudo -u postgres pgbackrest --stanza=postgres-cluster check


3. На репликах (автоматическая синхронизация):
- Patroni автоматически настроит archive_command на репликах после переключения ролей

---

### Важные нюансы:
1. Права доступа:
   sudo chmod 750 /var/lib/pgbackrest
sudo chown postgres:postgres /var/lib/pgbackrest


2. Конфигурация Patroni:
Убедитесь, что в /etc/patroni.yml есть:
   bootstrap:
dcs:
postgresql:
parameters:
archive_mode: "on"
archive_command: "pgbackrest --stanza=postgres-cluster archive-push %p"


3. После failover:
- Новый master автоматически становится источником для бэкапов
- Не нужно повторно создавать stanza

---

### Пример правильного вывода при создании stanza:
sudo -u postgres pgbackrest --stanza=postgres-cluster stanza-create
P00 INFO: stanza-create command begin 2.47: ...
P00 INFO: stanza-create command end: completed successfully
Задачи, которыми предстоит заниматься:

Установка и обновление PostgreSQL (15-16), планирование ресурсов;
Настройка бэкапов;
Настройка резервирования и высокой доступности (используем patroni, pg_auto_failover, repmgr);
Поддержка системы мониторинга (используем zabbix/grafana и mamonsu), разбор инцидентов;
Автоматизация задач администрирования (Ansible/bash/python);
Написание инструкций и технической документации;
Работа в команде из 3-х PostgreSQL дба. Базы данных до 10 ТБ, десятки серверов.
Что Мы ожидаем увидеть в успешном кандидате:
Опыт администрирования PostgreSQL/PostgresPro;
Опыт работы с Linux (используем CentOS, Oracle Linux, РедОС).
Будет плюсом:

Знание Docker;
Знание Ansible/bash/python;
Плюсом будет опыт миграции данных на PostgreSQL из Oracle/Sql Server.
Оптимизация PostgreSQL включает настройку нескольких ключевых параметров конфигурации сервера базы данных (postgresql.conf). Ниже приведены рекомендации по наиболее важным параметрам, влияющим на производительность системы:

### 1. Параметры памяти
PostgreSQL активно использует память для хранения часто используемых данных и промежуточных результатов запросов. Настройки зависят от объема оперативной памяти на сервере.

#### a) shared_buffers
Это объем памяти, выделяемый для общего буферного кеша SQL-запросов. Рекомендуется устанавливать примерно равным объему физической памяти сервера, деленному на число активных БД, минимум — около 25% доступной RAM.
Пример настройки:
shared_buffers = 8GB # если доступно ~32 ГБ ОЗУ


#### b) work_mem
Определяет объем памяти, используемый для сортировок и временных операций. Увеличение улучшает скорость сложных запросов, но чрезмерная настройка вызывает рост потребления памяти и проблемы с параллелизмом.
Рекомендуемое значение зависит от нагрузки и сложности запросов, примерное начальное значение:
work_mem = 128MB


#### c) maintenance_work_mem
Используется для операций обслуживания (например, VACUUM FULL, CREATE INDEX), увеличивайте осторожно, поскольку такие операции выполняются редко, но требуют много ресурсов.
Пример значения:
maintenance_work_mem = 1GB


### 2. Параметры журнала транзакций (WAL)
Правильная настройка WAL влияет на надежность и производительность записи.

#### d) wal_buffers
Размер буфера записей WAL. Если диски быстрые (SSD/NVMe), увеличьте этот параметр для повышения скорости синхронных записей:
wal_buffers = 16MB


#### e) checkpoint_timeout
Частота принудительных контрольных точек. Более длинные интервалы уменьшают нагрузку на систему, но увеличивают размер WAL-файлов между чекпоинтами:
checkpoint_timeout = 1h


#### f) max_wal_size
Максимальный размер файлов WAL перед созданием новой контрольной точки. Устанавливается достаточно большим для предотвращения частых проверок:
max_wal_size = 16GB


### 3. Параметры процессора и параллельных процессов
Эффективность многопоточности важна для современных многопроцессорных серверов.

#### g) effective_io_concurrency
Количество одновременных запросов ввода-вывода. Чем больше ядер и дисков SSD, тем большее значение допустимо. Для высокопроизводительного оборудования:
effective_io_concurrency = 200


#### h) max_worker_processes, max_parallel_workers_per_gather
Эти параметры определяют количество рабочих потоков для поддержки параллельного исполнения запросов:
max_worker_processes = 8
max_parallel_workers_per_gather = 4


### 4. Кэширование планов запросов
PostgreSQL автоматически кэширует планы запросов, чтобы избежать повторных оптимизаций.

#### i) plan_cache_mode
Контролирует поведение плана запросов при изменении статистики таблиц. Используйте значение auto для большинства случаев:
plan_cache_mode = auto


### 5. Автоматическая очистка (VACUUM AUTOVACUUM)
Регулярная автоматическая очистка помогает поддерживать консистентность и производительность таблиц путем удаления устаревших строк.

#### j) autovacuum_vacuum_scale_factor
Процент изменений таблицы, при достижении которого запускается автоочистка. Значение ниже уменьшает задержку очистки:
autovacuum_vacuum_scale_factor = 0.1


#### k) autovacuum_analyze_threshold
Минимальное количество вставленных/обновленных/удаленных строк, которое должно произойти перед запуском анализа статистики:
autovacuum_analyze_threshold = 1000


### 6. Другие важные параметры
- listen_addresses: Разрешить доступ к удаленным клиентам:
  listen_addresses = '*'


- log_min_duration_statement: Логгировать запросы дольше указанного времени (полезно для мониторинга медленных запросов):
  log_min_duration_statement = 1s


---

## Итоги

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

sudo systemctl restart postgresql


или выполнить команду внутри консоли psql:
SELECT pg_reload_conf();


Проверьте стабильность и производительность с новыми параметрами на тестовом стенде перед внедрением в продакшен!
Для автоматизации задач администрирования PostgreSQL существует ряд инструментов и подходов, позволяющих упростить рутинные задачи и повысить эффективность управления базой данных. Вот некоторые распространенные методы и примеры реализации таких задач:

### 1. Автоматическое резервное копирование баз данных
Один из важнейших аспектов администрирования — регулярное создание резервных копий.

Пример сценария на Bash для ежедневного полного бэкапа всех баз данных PostgreSQL:

#!/bin/bash

# Путь к каталогу для сохранения бекапа
BACKUP_DIR="/var/lib/postgres/backups"

# Дата и имя файла
DATE=$(date +"%Y-%m-%d")
FILENAME="backup-$DATE.sql.gz"

# Создаем полный дамп всех баз данных
pg_dumpall | gzip > "$BACKUP_DIR/$FILENAME"

# Убираем старые бекапы старше N дней (например, 7)
find "$BACKUP_DIR" -type f -name "*.gz" -mtime +7 -exec rm {} \;


### 2. Мониторинг состояния базы данных
Мониторинг важен для своевременного обнаружения проблем и принятия мер.

Пример скрипта на Python для проверки доступности службы PostgreSQL и размера базы данных:

import subprocess
from datetime import datetime

def check_postgres():
try:
result = subprocess.run(['psql', '-c', 'SELECT version()'], capture_output=True, text=True)
if result.returncode != 0 or not result.stdout.strip().startswith('PostgreSQL'):
print(f"[{datetime.now()}] ERROR: PostgreSQL service is down.")
else:
db_size_result = subprocess.run(['psql', '-c', 'SELECT pg_database_size(\'mydb\');'], capture_output=True, text=True)
size_mb = int(db_size_result.stdout.split()[2]) / (1024 * 1024)
print(f"[{datetime.now()}] Database mydb size: {size_mb:.2f} MB")
except Exception as e:
print(f"[{datetime.now()}] ERROR: {e}")

if __name__ == "__main__":
check_postgres()


Этот скрипт проверяет доступность сервиса и выводит текущий размер базы данных.

### 3. Планировщик задач cron
Использование crontab позволяет запланировать выполнение различных административных задач по расписанию.

Пример задания cron для еженедельной автоматической чистки старых журналов аудита:

# Удалять файлы журналов старше месяца каждую субботу утром
0 4 * * Sat find /var/log/postgres/audit -type f -mtime +30 -delete


### 4. Автоматический сбор статистики
Сбор статистики о работе базы данных полезен для оптимизации и устранения узких мест.

Пример bash-скрипта для автоматического сбора статистики о длительности выполнения запросов каждые 5 минут:

#!/bin/bash

LOG_FILE="/var/log/postgres/query_stats.log"

while true; do
echo $(date '+%F %T') >> $LOG_FILE
psql -c "SELECT now(), pid, datname, usename, state, query FROM pg_stat_activity WHERE state <> 'idle';" >> $LOG_FILE
sleep 300
done


### 5. Автоматизированная чистка ненужных объектов (vacuum/autovacuum)
Очистка базы данных важна для поддержания её производительности. Autovacuum работает автоматически, но иногда полезно настроить дополнительные сценарии для ручной очистки.

Пример bash-скрипта для запуска ручной очистки таблиц в заданное время:

#!/bin/bash

TABLES="table1 table2"

for TABLE in $TABLES; do
echo "Vacuuming table $TABLE..."
vacuumdb -vz -Z --analyze-only=false $TABLE
done


### 6. Использование специализированных инструментов
Существуют инструменты вроде PgBouncer, Patroni, pgAdmin, pgBadger, которые помогают автоматизировать мониторинг, балансировку соединений, управление кластерами и многое другое.

Например, PgBouncer управляет соединениями, уменьшая нагрузку на базу данных:

Простейший конфигурационный файл pgbouncer.ini:

[dbs]
mydatabase = host=localhost port=5432 user=postgres password=mypassword

[pgbouncer]
listen_addr = *
listen_port = 6432
auth_type = trust
pool_mode = session
server_reset_query = DISCARD ALL
default_pool_size = 20
min_pool_size = 5
reserve_pool_size = 5
### Заключение
Автоматизация задач администратора PostgreSQL значительно упрощает работу с большими объемами данных и снижает вероятность человеческих ошибок. Главное правило успешного внедрения автоматизации — постепенность и тщательное тестирование каждой процедуры.