thevar1able/ClickHouse
1
0
Fork 0
mirror of https://github.com/ClickHouse/ClickHouse.git synced 2024-11-22 15:42:02 +00:00
Code Issues Packages Projects Releases Wiki Activity

Apply suggestions from code review

Browse Source 
Co-authored-by: gyuton <40863448+gyuton@users.noreply.github.com>
This commit is contained in:
olgarev 2021-10-03 07:31:53 +03:00 committed by GitHub
parent 1020c25830
commit 5f1def135a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/en/engines/database-engines/materialized-postgresql.md
View File

@ -109,11 +109,11 @@ SELECT * FROM postgresql_db.postgres_table;
## Notes {#notes}
### Failover of the logical replication slot {logical-replication-slot-failover}
### Failover of the logical replication slot {#logical-replication-slot-failover}
Logical Replication Slots which exist on the primary are not available on standby replicas.
So if there is a failover, new primary (the old physical standby) won’t be aware of any slots which were existing with old primary. This will lead to a broken replication from PostgreSQL.
A solution to this is to manage replication slots yourself and define a permanent replication slot (some information can be found [here](https://patroni.readthedocs.io/en/latest/SETTINGS.html)). You'll need to pass slot name via `materialized_postgresql_replication_slot` setting, and it has to be exported with `EXPORT SNAPSHOT` option. The snapshot identifier needs to be passed via `materialized_postgresql_snapshot` setting.
A solution to this is to manage replication slots yourself and define a permanent replication slot (some information can be found [here](https://patroni.readthedocs.io/en/latest/SETTINGS.html)). You'll need to pass slot name via [materialized_postgresql_replication_slot](../../operations/settings/settings.md#materialized-postgresql-replication-slot) setting, and it has to be exported with `EXPORT SNAPSHOT` option. The snapshot identifier needs to be passed via [materialized_postgresql_snapshot](../../operations/settings/settings.md#materialized-postgresql-snapshot) setting.
**Example (from [@bchrobot](https://github.com/bchrobot))**

6
docs/ru/engines/database-engines/materialized-postgresql.md
View File

@ -88,11 +88,11 @@ SELECT * FROM postgresql_db.postgres_table;
```
## Примечания {#notes}
### Сбой слота логической репликации {logical-replication-slot-failover}
### Сбой слота логической репликации {#logical-replication-slot-failover}
Слоты логической репликации, которые есть на основном сервере, не доступны на резервных репликах.
Поэтому в случае сбоя новый основной сервер (который раньше был резевным) не будет знать о слотах репликации, которые были созданы на вышедшем из строя основном сервере. Это приведет к нарушению репликации из PostgreSQL.
Решением этой проблемы может стать ручное управление слотами репликации и определение постоянного слота репликации (об этом можно прочитать [здесь](https://patroni.readthedocs.io/en/latest/SETTINGS.html)). Этот слот нужно назначить с помощью настройки `materialized_postgresql_replication_slot`, и он должен быть экспортирован в параметре `EXPORT SNAPSHOT`. Идентификатор снэпшота нужно передать в настройке `materialized_postgresql_snapshot`.
Решением этой проблемы может стать ручное управление слотами репликации и определение постоянного слота репликации (об этом можно прочитать [здесь](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))**
@ -134,7 +134,7 @@ SETTINGS
materialized_postgresql_tables_list = 'table1,table2,table3';
```
4. Когда БД в ClickHouse создастся, завершите транзакцию в PostgreSQL. Убедитесь, что репликация продолжается после сбоя:
4. Когда начнет выполняться репликация БД в ClickHouse, прервите транзакцию в PostgreSQL. Убедитесь, что репликация продолжается после сбоя:
```bash
kubectl exec acid-demo-cluster-0 -c postgres -- su postgres -c 'patronictl failover --candidate acid-demo-cluster-1 --force'