Здравствуйте!
Используем Конфигурацию УТ10.3,
клиент-сервер, 64-бит
Версия предприятия 8.3.14.1779
Версия postgresql 10.10-4.1C
ОС Windows server 2008R2
Core i7 4770, 32GB ОЗУ, SSD
Работающих пользователей до 30
Вечером при перепроведении документов программистом 1С под администратором произошел сбой. С базой в этот момент кроме него никто не работал. По его словам из предприятия и из конфигуратора выкинуло.
лог postgresql прикрепил
После перезахода в базу выяснилось, что в журнале вообще не отображаются документы за даты с 29 февраля по 5 марта.
Т.к. до перепроведения был сделан бэкап в DT, решили развернуть его.
Кроме того, базу развернули в MSSQL Express из-за опасений повторения ошибки на postgresql.
Поиски в интернете показали, что подобная ошибка действительно специфична при работе с postgresql. Каких-то "железобетонных" рецептов ее избежать найти не удалось.
Прошу высказать Ваше мнение насчет дальнейшей работы. Мы сейчас решаем, стоит ли покупать полную версию MSSQL (экспресса хватит в лучшем случае до конца года) или пытаться остаться на postgresql. Сколько стоит mssql - понятно. Во что обойдутся попытки остаться с postgresql? Можно ли избежать таких сбоев при использовании postgresql?
Используем Конфигурацию УТ10.3,
клиент-сервер, 64-бит
Версия предприятия 8.3.14.1779
Версия postgresql 10.10-4.1C
ОС Windows server 2008R2
Core i7 4770, 32GB ОЗУ, SSD
Работающих пользователей до 30
Вечером при перепроведении документов программистом 1С под администратором произошел сбой. С базой в этот момент кроме него никто не работал. По его словам из предприятия и из конфигуратора выкинуло.
лог postgresql прикрепил
После перезахода в базу выяснилось, что в журнале вообще не отображаются документы за даты с 29 февраля по 5 марта.
Т.к. до перепроведения был сделан бэкап в DT, решили развернуть его.
Кроме того, базу развернули в MSSQL Express из-за опасений повторения ошибки на postgresql.
Поиски в интернете показали, что подобная ошибка действительно специфична при работе с postgresql. Каких-то "железобетонных" рецептов ее избежать найти не удалось.
Прошу высказать Ваше мнение насчет дальнейшей работы. Мы сейчас решаем, стоит ли покупать полную версию MSSQL (экспресса хватит в лучшем случае до конца года) или пытаться остаться на postgresql. Сколько стоит mssql - понятно. Во что обойдутся попытки остаться с postgresql? Можно ли избежать таких сбоев при использовании postgresql?
Прикрепленные файлы:
pg.txt
Найденные решения
(7)
Вообще, есть отличный механизм у постгреса . Там в конфиге просто прописывается команда copy %p X:\backup\%f - что-то такое. В итоге происходит непрерывный бэкап. Сломалось что? Копипастишь каталог базы, уладяешь в нем лишнее, помещаешь туда файлик конфига для восстановления, в котором пишешь команду обратного копирования и инфу о том, на какую секунду развернуть базу - и все! Можно потом переиграть, если секунда не понравилась. И ничего никуда не пропадает. Для бэкапов достаточно даже обычных HDD, т.к. WAL-файлы обычно 16 метров и пишутся один раз последовательно - никакой перезаписи.
В журналах системы чисто, никаких ошибок.
На винде?
Вообще, есть отличный механизм у постгреса . Там в конфиге просто прописывается команда copy %p X:\backup\%f - что-то такое. В итоге происходит непрерывный бэкап. Сломалось что? Копипастишь каталог базы, уладяешь в нем лишнее, помещаешь туда файлик конфига для восстановления, в котором пишешь команду обратного копирования и инфу о том, на какую секунду развернуть базу - и все! Можно потом переиграть, если секунда не понравилась. И ничего никуда не пропадает. Для бэкапов достаточно даже обычных HDD, т.к. WAL-файлы обычно 16 метров и пишутся один раз последовательно - никакой перезаписи.
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Суть лога в том, что при попытке обновить данные в журнале документов система столкнулась со сбоем - не нашла таблицу соответствующего документа. Возможно у Вас диск сбойнул (не серверный, как я понимаю), или память (без ЕСС, как я понимаю). Не думаю, что с MS SQL при таком "надежном" железе будет сильно лучше, т.к. если сбойнет диск или память, то этот сбой на стороне ОС обрабатывается и до СУБД может и не дойти.
Для такого железа есть возможность или записи WAL-файлов (непрерывный бэкап), или потоковая репикация на второй инстанс постгреса (их можно запустить в принципе сколько угодно даже на одной машине). В первом случае Вы получите возможность развернуть базу на любой момент, во втором случае - просто переключиться (даже в автоматическом режиме) на рабочий инстанс - сделать его мастером (но если это будет на одном компе и не в разных виртуалках/контейнерах, то придется еще порт подключения менять, поэтому контейнеризация - это ВЕЩЬ!)
Для такого железа есть возможность или записи WAL-файлов (непрерывный бэкап), или потоковая репикация на второй инстанс постгреса (их можно запустить в принципе сколько угодно даже на одной машине). В первом случае Вы получите возможность развернуть базу на любой момент, во втором случае - просто переключиться (даже в автоматическом режиме) на рабочий инстанс - сделать его мастером (но если это будет на одном компе и не в разных виртуалках/контейнерах, то придется еще порт подключения менять, поэтому контейнеризация - это ВЕЩЬ!)
(7)
Вообще, есть отличный механизм у постгреса . Там в конфиге просто прописывается команда copy %p X:\backup\%f - что-то такое. В итоге происходит непрерывный бэкап. Сломалось что? Копипастишь каталог базы, уладяешь в нем лишнее, помещаешь туда файлик конфига для восстановления, в котором пишешь команду обратного копирования и инфу о том, на какую секунду развернуть базу - и все! Можно потом переиграть, если секунда не понравилась. И ничего никуда не пропадает. Для бэкапов достаточно даже обычных HDD, т.к. WAL-файлы обычно 16 метров и пишутся один раз последовательно - никакой перезаписи.
В журналах системы чисто, никаких ошибок.
На винде?
Вообще, есть отличный механизм у постгреса . Там в конфиге просто прописывается команда copy %p X:\backup\%f - что-то такое. В итоге происходит непрерывный бэкап. Сломалось что? Копипастишь каталог базы, уладяешь в нем лишнее, помещаешь туда файлик конфига для восстановления, в котором пишешь команду обратного копирования и инфу о том, на какую секунду развернуть базу - и все! Можно потом переиграть, если секунда не понравилась. И ничего никуда не пропадает. Для бэкапов достаточно даже обычных HDD, т.к. WAL-файлы обычно 16 метров и пишутся один раз последовательно - никакой перезаписи.
(3) что имеется ввиду под "готовить PG". Настроить параметры конфига 1 раз под железо и нагрузку? Эту услугу можно даже заказать. Но как это поможет предотвратить подобный сбой
(2) Я, к сожалению, не знаю. Программист 1С только ругался разными словами в сторону posgresql и говорил, что на mssql у него "такого никогда не было" (С)
(2) Я, к сожалению, не знаю. Программист 1С только ругался разными словами в сторону posgresql и говорил, что на mssql у него "такого никогда не было" (С)
(4) я с PG не работал, но знаю, что она очень чувствительная дама. И любой чих заставляет ее плакать.
Настройки никак не помогут, тут многое зависит от самого программиста. В идеале это должен быть эксперт по технологическим вопросам, который знает, как нужно обращаться с PG, чтобы не было проблем.
А с МС любой среднячок сможет справиться. В этом плане МС сродни матери, которая все постарается понять и простить
Настройки никак не помогут, тут многое зависит от самого программиста. В идеале это должен быть эксперт по технологическим вопросам, который знает, как нужно обращаться с PG, чтобы не было проблем.
А с МС любой среднячок сможет справиться. В этом плане МС сродни матери, которая все постарается понять и простить
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот