C
Кто-нибудь уже до 8.3.18 обновился ?
Size: a a a
2020 November 01
C
поставил сервер и пишет теперь:
C
root@srv-1c:~# systemctl status *1c*
Unit 1c-enterprise-8.3.18.1128-common_8.3.18-1128_amd64.deb.service could not be found.
Unit 1c-enterprise-8.3.18.1128-server_8.3.18-1128_amd64.deb.service could not be found.
Unit 1c-enterprise-8.3.18.1128-ws_8.3.18-1128_amd64.deb.service could not be found.
root@srv-1c:~# service 1csrv83 start
Failed to start 1csrv83.service: Unit 1csrv83.service not found.
Unit 1c-enterprise-8.3.18.1128-common_8.3.18-1128_amd64.deb.service could not be found.
Unit 1c-enterprise-8.3.18.1128-server_8.3.18-1128_amd64.deb.service could not be found.
Unit 1c-enterprise-8.3.18.1128-ws_8.3.18-1128_amd64.deb.service could not be found.
root@srv-1c:~# service 1csrv83 start
Failed to start 1csrv83.service: Unit 1csrv83.service not found.
СГ
root@srv-1c:~# systemctl status *1c*
Unit 1c-enterprise-8.3.18.1128-common_8.3.18-1128_amd64.deb.service could not be found.
Unit 1c-enterprise-8.3.18.1128-server_8.3.18-1128_amd64.deb.service could not be found.
Unit 1c-enterprise-8.3.18.1128-ws_8.3.18-1128_amd64.deb.service could not be found.
root@srv-1c:~# service 1csrv83 start
Failed to start 1csrv83.service: Unit 1csrv83.service not found.
Unit 1c-enterprise-8.3.18.1128-common_8.3.18-1128_amd64.deb.service could not be found.
Unit 1c-enterprise-8.3.18.1128-server_8.3.18-1128_amd64.deb.service could not be found.
Unit 1c-enterprise-8.3.18.1128-ws_8.3.18-1128_amd64.deb.service could not be found.
root@srv-1c:~# service 1csrv83 start
Failed to start 1csrv83.service: Unit 1csrv83.service not found.
Вручную копируете srv1cv83 в /etc/init.d/ и включаете его
systemctl enable srv1cv83М
Вывод? Мешает винда с 1с сервером:)
Выход: использовать debian
М
Или лучше freebsd
П
Или лучше freebsd
фряха не всем дается
A
Ну постгрес же не сам будет разжимать, а какой-нибудь gunzip или gzip. Попробуйте разжать свой текущий gz.partial
gzip не хочет расжимать
нагуглил, кто-то использует zcat
попробовал - что-то расжалось, перенаправил поток в файл
натравил pg_waldump - он что-то выводит (транзакции), а потом, когда доходит до "конца" пишет:
pg_waldump: FATAL: could not read from log file 000000010000086700000061, offset 11829248, length 8192: Success
нагуглил, кто-то использует zcat
попробовал - что-то расжалось, перенаправил поток в файл
натравил pg_waldump - он что-то выводит (транзакции), а потом, когда доходит до "конца" пишет:
pg_waldump: FATAL: could not read from log file 000000010000086700000061, offset 11829248, length 8192: Success
GS
да, zcat + truncate вроде нормально прочитало
A
А после zcat + truncate получается "нормальный" .partial?
Я имею ввиду, сможет ли его прочитать при восстановлении PG?
Потому как pg_waldump в конце ругается
Я имею ввиду, сможет ли его прочитать при восстановлении PG?
Потому как pg_waldump в конце ругается
GS
Alexander Malykhin
А после zcat + truncate получается "нормальный" .partial?
Я имею ввиду, сможет ли его прочитать при восстановлении PG?
Потому как pg_waldump в конце ругается
Я имею ввиду, сможет ли его прочитать при восстановлении PG?
Потому как pg_waldump в конце ругается
ну это нормально, он хочет видеть файл равный wal_segment_size
GS
короче проблема в том, что gzwrite() сбрасывает пожатые данные по мере накопления буфера
GS
и, соответственно, пока он не наполнится, "хвост" находится только в памяти
GS
короче pg_receivewal нарушает гарантии, которые дает --synchronous и всегда есть риск потерять последние данные
A
Хмм, а я как раз --synchronous включил...
GS
хотя нет, может я ошибаюсь
A
Ну у меня есть реплика - на ней последний WAL, даже частичный все равно будет на месте, собственно как и данные
И, получается, что параметр archive_timeout в данной ситуации будет полезен - можно задать интервал, и хотя бы четко понимать, за какой период возможна потеря данных
И, получается, что параметр archive_timeout в данной ситуации будет полезен - можно задать интервал, и хотя бы четко понимать, за какой период возможна потеря данных
GS
ну так реплика не жмет файлы в gz
GS
ща проверю эту гипотезу