MV
postgresql-common требуется разных версий для pgpro и postgresql-10-1C
как видите это не так.
Size: a a a
2020 September 30
P
как видите это не так.
Если бы так... у меня требовалось "скрестить" запуск на одном сервере:
postgresql-10 10.11-5.1C
postgrespro-1c-11
postgresql-10 10.11-5.1C
postgrespro-1c-11
MV
не понимаю о чём спор. Я посмотрел зависимости pgpro, в них нет никакого postgresql-common
P
не понимаю о чём спор. Я посмотрел зависимости pgpro, в них нет никакого postgresql-common
# dpkg -i ./postgresql-10_10.11-5.1C_amd64.deb
Выбор ранее не выбранного пакета postgresql-10.
(Чтение базы данных … на данный момент установлено 134946 файлов и каталогов.)
Подготовка к распаковке …/postgresql-10_10.11-5.1C_amd64.deb …
Распаковывается postgresql-10 (10.11-5.1C) …
dpkg: зависимости пакетов не позволяют настроить пакет postgresql-10:
postgresql-10 зависит от postgresql-common (>= 182~), однако:
Пакет postgresql-common не установлен.P
# aptitude install postgresql-common
Следующие НОВЫЕ пакеты будут установлены:
postgresql-common
Следующие частично установленные пакеты будут настроены:
postgresql-10{b}
0 пакетов обновлено, 1 установлено новых, 0 пакетов отмечено для удаления, и 0 пакетов не обновлено.
Необходимо получить 154 kБ архивов. После распаковки 613 kБ будет занято.
Следующие пакеты имеют неудовлетворённые зависимости:
postgrespro-1c-11 : Конфликтует: postgresql-common но будет установлен 173ubuntu0.3.
Конфликтует: postgresql-common:i386 which is a virtual package, provided by:
- postgresql-common, но будет установлен 173ubuntu0.3. - postgresql-common, но будет установлен 173ubuntu0.3. - postgresql-common, но будет установлен 173ubuntu0.3.
postgresql-10 : Зависит: postgresql-common (>= 182~) но будет установлен 173ubuntu0.3.
Следующие действия разрешат зависимости:
Удалить следующие пакеты:
1) postgrespro-1c-11
2) postgresql-10P
А сами сервисы встали и в системе присутствуют... pgpro даже работает... а вот postgresql-10 1C не желает работать без postgresql-common причём версии меньше чем 182, но при установке хоть меньшей, хоть большей версии предлагается снести оба сервиса чтобы мозг не мучали никому
MV
ставьте все пакеты 1с из тех, что идут в комплекте
A
Да распакуйте deb пакет pgpro руками и положите в /opt - там как раз все в одном месте лежит
И конфиги там лежат в data, так что пересекаться никак не будут.
unit systemd руками скопировать и положить
из минусов - обновлять тоже руками будете
И конфиги там лежат в data, так что пересекаться никак не будут.
unit systemd руками скопировать и положить
из минусов - обновлять тоже руками будете
И
Контейнеризация..
+
A
Валидация при слиянии бэкапов выполняется
Григорий, подскажите, что оно хочет мне сказать:
13:05:01 : INFO: command: pg_probackup-11 backup -B /srv/storage/postgres_backup -b PAGE --instance=pgsrv --stream —temp-slot --log-level-console=off -j 1
13:05:01 : INFO: Backup start, pg_probackup version: 2.4.2, instance: pgsrv, backup ID: QHGUOD, backup mode: PAGE, wal mode: STREAM, remote: false, compress-algorithm: zlib, compress-level: 6
13:05:02 : INFO: Backup QHGUOD is going to be taken from standby
13:05:49 : ERROR: query failed: ERROR: canceling statement due to conflict with recovery
DETAIL: User query might have needed to see row versions that must be removed. query was: SELECT pg_catalog.pg_start_backup($1, $2, false)
13:05:49 : WARNING: Backup QHGUOD is running, setting its status to ERROR
Бэкап снимается с реплики, несколько дней все было ровно, предыдущий (ночной) - ОК, следом руками запустил ту же команду - отработало нормально. В логах postgres-а тоже самое.
13:05:01 : INFO: command: pg_probackup-11 backup -B /srv/storage/postgres_backup -b PAGE --instance=pgsrv --stream —temp-slot --log-level-console=off -j 1
13:05:01 : INFO: Backup start, pg_probackup version: 2.4.2, instance: pgsrv, backup ID: QHGUOD, backup mode: PAGE, wal mode: STREAM, remote: false, compress-algorithm: zlib, compress-level: 6
13:05:02 : INFO: Backup QHGUOD is going to be taken from standby
13:05:49 : ERROR: query failed: ERROR: canceling statement due to conflict with recovery
DETAIL: User query might have needed to see row versions that must be removed. query was: SELECT pg_catalog.pg_start_backup($1, $2, false)
13:05:49 : WARNING: Backup QHGUOD is running, setting its status to ERROR
Бэкап снимается с реплики, несколько дней все было ровно, предыдущий (ночной) - ОК, следом руками запустил ту же команду - отработало нормально. В логах postgres-а тоже самое.
GS
постгрес пристрелил наш запрос
GS
включение параметра
hot_standby_feedback должно точно решить эту проблемуGS
запросы на реплике гоняете?
A
запросы на реплике гоняете?
нет, реплика только чтобы бэкапы снимать и отдавать wal-ы pg_receivewal
GS
ну тогда можно просто включить
hot_standby_feedbackA
ну тогда можно просто включить
hot_standby_feedbackя так понял, что сошлись звезды и на мастере автовакуум сработал и из-за этого реплика была вынуждена "послать" клиента?
GS
бэкенд, выполнявший start_backup пошел читать какие-то туплы (видимо в каталоге), для которых как раз применялся WAL
СГ
включение параметра
hot_standby_feedback должно точно решить эту проблемуможет проще разрешить небольшой лаг для реплики? А то случайным долгим запросом на реплике можно блоатинг на мастере сотворить с этой опцией
GS
может проще разрешить небольшой лаг для реплики? А то случайным долгим запросом на реплике можно блоатинг на мастере сотворить с этой опцией
можно и так, но товарищ вроде сказал, что клиентских запросов на реплике нет
СГ
Alexander Malykhin
я так понял, что сошлись звезды и на мастере автовакуум сработал и из-за этого реплика была вынуждена "послать" клиента?
а покажите
show max_standby_streaming_delay;