Update materialized-postgresql.md

This commit is contained in:
Kseniia Sumarokova 2021-10-03 20:22:23 +03:00 committed by GitHub
parent fbcb2b0624
commit b0818698b6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -94,9 +94,11 @@ SELECT * FROM postgresql_db.postgres_table;
Поэтому в случае сбоя новый основной сервер (который раньше был резевным) не будет знать о слотах репликации, которые были созданы на вышедшем из строя основном сервере. Это приведет к нарушению репликации из PostgreSQL.
Решением этой проблемы может стать ручное управление слотами репликации и определение постоянного слота репликации (об этом можно прочитать [здесь](https://patroni.readthedocs.io/en/latest/SETTINGS.html)). Этот слот нужно передать с помощью настройки [materialized_postgresql_replication_slot](../../operations/settings/settings.md#materialized-postgresql-replication-slot), и он должен быть экспортирован в параметре `EXPORT SNAPSHOT`. Идентификатор снэпшота нужно передать в настройке [materialized_postgresql_snapshot](../../operations/settings/settings.md#materialized-postgresql-snapshot).
Имейте в виду, что это стоит делать только если есть реальная необходимость. Если такой необходимости нет, или если нет полного понимания того, как это работает, то самостоятельно слот репликации конфигурировать не стоит, он будет создан таблицей.
**Пример (от [@bchrobot](https://github.com/bchrobot))**
1. Сконфигурируйте слот репликации в PostgreSQL. Имейте в виду, что это стоит делать только если есть реальная необходимость. Если такой необходимости нет, или если нет полного понимания того, как это работает, слот репликации конфигурировать не стоит.
1. Сконфигурируйте слот репликации в PostgreSQL.
```yaml
apiVersion: "acid.zalan.do/v1"
@ -138,4 +140,4 @@ SETTINGS
```bash
kubectl exec acid-demo-cluster-0 -c postgres -- su postgres -c 'patronictl failover --candidate acid-demo-cluster-1 --force'
```
```