Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
WARNING: archiving transaction log file failed too many times
|
|||
|---|---|---|---|
|
#18+
Что-то не могу сообразить в чем проблема. В логе 2016-08-23 04:10:38 AST [5203-7999] LOG: archive command failed with exit code 1 2016-08-23 04:10:38 AST [5203-8000] DETAIL: The failed archive command was: ssh postgres@172.17.41.215 test ! -e /backups/wals/0000000D000000000000008C && scp pg_xlog/0000000D000000000000008C postgres@172.17.41.215:/backups/wals/0000000D000000000000008C 2016-08-23 04:10:38 AST [5203-8001] WARNING: archiving transaction log file "0000000D000000000000008C" failed too many times, will try again later На архивном сервере [postgres@pg-archive1.cur:backups]$ ls -la /backups/wals/0000000D000000000000008C -rw------- 1 postgres postgres 16777216 Aug 22 06:59 /backups/wals/0000000D000000000000008C Два вопроса : 1)По моему нормальная ситуация - файл уже есть, архивировать его не надо , но почему запись в лог идет? 2)как избавится от ситуации ? checkpoint n pg_switch_xlog() делал. Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.08.2016, 11:22 |
|
||
|
WARNING: archiving transaction log file failed too many times
|
|||
|---|---|---|---|
|
#18+
Может, отказаться вообще от archive command и запустить на удалённой машине pg_receivexlog? Какой код возврата от test? От test поверх ssh? От scp? Может, кто-нибудь из них что интересное пишет в stdout/stderr - не помню, будет ли это попадать в лог pg. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.08.2016, 11:39 |
|
||
|
WARNING: archiving transaction log file failed too many times
|
|||
|---|---|---|---|
|
#18+
Melkij, Спасибо за наводки, по поводу pg_receivexlog - надо подумать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.08.2016, 12:26 |
|
||
|
WARNING: archiving transaction log file failed too many times
|
|||
|---|---|---|---|
|
#18+
Melkij, > отказаться вообще от archive command и запустить на удалённой машине pg_receivexlog это не одно и тоже вообщето ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2016, 00:29 |
|
||
|
WARNING: archiving transaction log file failed too many times
|
|||
|---|---|---|---|
|
#18+
Misha Tyurin, как пруф, могу сослаться на доклад Magnus Hagander с pgday16: http://pgday.ru/ru/2016/papers/53 Где прямым текстом сказано не используйте archive_command для получения wal для PitR, используйте pg_receivexlog (плюс, с replication slot) К сожалению, не знаю, выложили ли уже записи с конференции - вроде бы ещё нет. Ваши возражения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2016, 08:46 |
|
||
|
WARNING: archiving transaction log file failed too many times
|
|||
|---|---|---|---|
|
#18+
MelkijMisha Tyurin, как пруф, могу сослаться на доклад Magnus Hagander с pgday16: http://pgday.ru/ru/2016/papers/53 Где прямым текстом сказано не используйте archive_command для получения wal для PitR, используйте pg_receivexlog (плюс, с replication slot) Он приводил какие-то аргументы почему `archive_command` вдруг стала плоха? (Я не был на его докладе.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2016, 09:32 |
|
||
|
WARNING: archiving transaction log file failed too many times
|
|||
|---|---|---|---|
|
#18+
vyegorov, Основной довод из доклада: archive_command срабатывает после формирования WAL файла. Затем идет обычная команда OS по действию над этим файлом. В случае падения сервера имеем промежуток времени в течение которого файл сформирован, но действие еще не выполнено. Автоматического повторения действия не предпринимается. В результате этого может произойти потеря фала. pg_receivexlog работает как еще один клиент, получающий данные для репликации. То есть обращается напрямую к БД и получает те данные, которые еще не забраны. Действия выполняются в более "реальном времени", данные гарантированно уходят на внешний сервер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2016, 11:17 |
|
||
|
WARNING: archiving transaction log file failed too many times
|
|||
|---|---|---|---|
|
#18+
vyegorov, мне кажется что да, несколько причин называл. Но я не записал. Одну причину вижу в мануале: https://www.postgresql.org/docs/9.4/static/app-pgreceivexlog.html авторpg_receivexlog streams the transaction log in real time as it's being generated on the server, and does not wait for segments to complete like archive_command does Больше ничего конкретного не могу вспомнить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2016, 11:32 |
|
||
|
WARNING: archiving transaction log file failed too many times
|
|||
|---|---|---|---|
|
#18+
vyegorovMelkijMisha Tyurin, как пруф, могу сослаться на доклад Magnus Hagander с pgday16: http://pgday.ru/ru/2016/papers/53 Где прямым текстом сказано не используйте archive_command для получения wal для PitR, используйте pg_receivexlog (плюс, с replication slot) Он приводил какие-то аргументы почему `archive_command` вдруг стала плоха? (Я не был на его докладе.) pg_receivexlog куда сложнее сделать неверно а 99% archive_commands что я видел в поле - они неверны в корне просто. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2016, 11:54 |
|
||
|
WARNING: archiving transaction log file failed too many times
|
|||
|---|---|---|---|
|
#18+
Melkij, > (плюс, с replication slot) вот, хорошо, это надо было вспомнить. да. // иначе как это ввели в бой в 92 было совсем непригодно. и еще только относительно недавно там начали fsync делать. а теперь представьте, что у вас нагруженный мастер на пару-тройку-... сотен MBit/sec wal трафика на выходе, и N стендбаев. и вы тогда съедаете канал пропорционально N. а при archive command вы съедаете всегда только 1, и можете еще жать так сильно, как будете успевать по cpu. там всякие еще тонкости есть, в итоге я бы 99% Максима обобщил бы на все архивы без относительно способов оправки/получения валов. а по поводу archive command -- система развивается также, и вот щас сделали режим always, например, крайне полезный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.08.2016, 16:25 |
|
||
|
WARNING: archiving transaction log file failed too many times
|
|||
|---|---|---|---|
|
#18+
Misha TyurinMelkij, а теперь представьте, что у вас нагруженный мастер на пару-тройку-... сотен MBit/sec wal трафика на выходе, и N стендбаев. и вы тогда съедаете канал пропорционально N. а при archive command вы съедаете всегда только 1, и можете еще жать так сильно, как будете успевать по cpu. Если у вас столько WAL и такие нагрузки - нет проблемы сделать 10GBit сетку на базе (IMHO 10gbit На базе вообще на любой стоит по умолчанию иметь если там хоть какая то нагрузка ожидается... 1Gbit - это сетка для дома и офиса). Ну и отставание реплик с streaming сильно меньше (а в 9.6 можно будет syncronous_commit=remote_apply иметь и вообще иметь реплики синхронные с мастером по чтению). -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.08.2016, 09:27 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=39296110&tid=1997041]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
184ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
| others: | 16ms |
| total: | 302ms |

| 0 / 0 |
