Еще бы документооборот

У нас вроде как намечается на горизонте еще одно тестирование, уже в другой компании. Возможно, там будет документооборот.

Эх, на линуксовых бы клиентах, с вэбом и ЕРП-УТ-Док

да плюс еще с РБД

и обменами с БП-Сайтами и прочими...

https://pgconf.ru/2016/90069

Друзья, вопрос задам по RAID?

Есть HP DL380 Gen8 и встроенный контроллер B320i. Купил P420. Он подхватит все Array? Или не факт?

Друзья, вопрос задам по RAID?

для этого нужно себе ответить на вопрос где хранится инфа о массивах. Варианты: 1. В мозгу контроллера 2. На дисках

для этого нужно себе ответить на вопрос где хранится инфа о массивах. Варианты: 1. В мозгу контроллера 2. На дисках

Ну в теории она хранится на дисках. Поэтому и задал вопрос. Может кто сталкивался

про "на дисках" - это очень смелое утверждение

здесь https://habrahabr.ru/company/advanserv/blog/163451/ утверждается, что на дисках

Мы в наших тестах 1С столкнулись с интересным моментом. Довольно часто 1С забывает закоммитить транзакцию. Сталкивался ли кто с аналогичным поведением или это какой-то наш локальный артефакт?

При проведении "отказ" по некоторым причинам, например нет товаров на складе, транзакция есть, коммита нет Если я все правильно понял

Сейчас это нормальная практика, залить данные, проверить есть ли записи меньше нуля по таблице

я не знаю, как это со стороны 1С выглядит, со стороны постгреса это выглядит так - пришло соединение, сказало BEGIN, поапдейтило что-то и сидит

примерно так: https://gist.github.com/gsmol/79a74425537a563a5dca67f4b95fecd4

Добрый день. Использую PostgreSQL 9.4.9 1C сборка от postgrespro. На эту версию перешли относительно недавно, до этого был 9.3.4 1C. Довольно часто ловлю такие вот ошибки index "pg_depend_reference_index" contains unexpected zero page at block 191. Statement: create temporary table tt1... Информационная база - зарплата и управление персоналом. Ошибка возникает почти при аналогичных условиях: База работает, затем ночью проходит создание дампа, отключение клиентов (остановка сервера 1с, остановка сервиса postgresql), далее архивируются и подчищаются wal'ы и снова старт postgresql и 1C. Далее начинается проблема описанная выше. Возникает не каждый раз и не каждый день, но уже с регулярностью. Кто-то сталкивался с подобной проблемой? Куда копать? Почему postgres начинает сыпаться на операциях с временными таблицами? Может проблема в online_analyze проходящего с патчем 1с? Его настройки выставлены по умолчанию.

похоже на покоррапченный индекс, пробовали делать реиндекс? REINDEX TABLE pg_catalog.pg_depend;

Регулярно при появлении ошибки.

Но ситуация повторяется

странно, не может ли быть проблема с дисками?

fsync включен?

dmesg молчит. ОС Centos 7.2 lvm + xfs. Все это дело крутится в виртуалке esxi. Все настройки postgres выставленны в макс сохранность. Fsync, full_page_write, synchronous_commit все включено.

Кластер с чексуммами.

На том же гипервизоре работает еще тьма виртуалок, правда в основе win машины - там все ок.

и ломается индекс после этой ночной рутины?

Да

значит что-то Вы там неправильно делаете =)(с) кэп

Ну я готов предположить такой момент. Вопрос в том что не так :)

хм, не может ли быть что сервер 1с работает во время дампа?

подозреваю, что такое кол-во слоев абстракций между данными и дисками - виртуалка,lvm - может играть роль

хм, не может ли быть что сервер 1с работает во время дампа?

Нет. 1с точно отключается.

хм, не может ли быть что сервер 1с работает во время дампа?

Да и сложно предположить что это повлияло бы. Ну будет дамп не консистентный.

Каким образом это может повлиять на работу индекса в конкретной базе - не знаю даже.

Да и причем между моментом снятия дампа и остановкой сервера постгреса промежуток в час.

а Вы валы вручную после остановки подчищаете?

Там на самом деле как-то так : 4:00 останавливаем 1с, делаем дамп. Восстанавливаем дамп в тестовую базу, поднимаем 1с. 5:30 отставка 1с, остановка postgresql, подчищаем wal и их убираем в архив, запускаем postgres, делаем basebackup, запускаем 1с. Далее ловим ошибки.

Скриптом. Подчищаю из некоего архива на другом диске куда они уходят через archive_command

Каталог постгреса не трогаю вообще.

попробуйте делать все тоже самое, но без остановки постгреса

Вы думаете что остановка постгреса больное место?

ну похоже на то

или хотя бы сделайте checkpoint перед остановкой

конкретно в вашем случае больное место =)

подозреваю, что такое кол-во слоев абстракций между данными и дисками - виртуалка,lvm - может играть роль

Ну тогда оно бы сыпалось на мой взгляд и в другие моменты времени, ну или по крайней мере давно были бы какие-то юзкейсы или противопоказания к использованию такой связки.

конкретно в вашем случае больное место =)

Ну это как-то странно :)

Кстати, еще уделю внимание тому что реально сами запросы во время возникновения проблемы обычно представляют собой работу со временными таблицами. Т.е. запускаются задания планировщика 1с

вот почему и вопрос о работающей 1с

вот почему и вопрос о работающей 1с

На момент выполнения работ над бд 1с уже выключен. Да и проводимые работы по сути с таблицами ничего не делают, дамп, архивирование валов, старт и базовая копия. И то в эти моменты 1с выключен. Проблемы приходят после выполнения работ и старта 1с

Кстати, еще уделю внимание тому что реально сами запросы во время возникновения проблемы обычно представляют собой работу со временными таблицами. Т.е. запускаются задания планировщика 1с

Совершенно необоснованный вывод

При старте Постгреса в его логе есть такие сообщения:

database system was not properly shut down; automatic recovery in progress

redo starts at 0/9A3F58

Нет

Он норм стартует. И выключается.

Совершенно необоснованный вывод

Предположение всего лишь. Временные таблицы 1ски

По тексту ошибки, проблема не с временными таблицами, а с индексом системной таблицы pg_depend...

Да, проявляется при работе со временной табличкой, но в целом да, согласен что проблема в ней. Но я ее переиндексировал каждый раз после возникновения ошибки, но она все равно возвращается.

Коллеги писали: Попробуйте не перезапускать Постгрес (если возможно) пару дней...

У нас такие ошибки с индексами бывают при неправильном останове Постгреса...

У нас такие ошибки с индексами бывают при неправильном останове Постгреса...

Обычный service postgreql-9.4 stop / start разве можно назвать не правильной остановкой? При этом логи этих процессов нормальные.

Вообще если отталкиваться от того что проблема в этом месте, то как-то все странно и плохо получается. Любой легетимный рестарт вдруг может породить неприятности.

Да, все правильно, но pg_ctl stop сначала пытается остановить все в смарт режиме, а потом (если не получается в смарт), то принудительно рубит соединения...

Я думаю это бы отражалось как-то в логах, а по ним все ОК. Да и из соединений там должны на этот момент остаться только служебные процессы типа вакуума

Да, у нас в логах после этого появляется инфа про redo...

ERROR: S client not available

Вот, а у меня тишь да гладь. У вас какая версия постгреса?

9.4.6, 9.4.8 от postgrespro, но тоже было и на 9.2 от 1С...

Оказывается уже в самом Github признали существование 1С как языка. https://github.com/search?&q=language%3A%221C+Enterprise%22&type=Repositories&ref=searchresults

Вот это поворот, скоро может даже будем гит использовать)

Но у него же нет даже названия

кто как думает, 1с с версии 8.5.4 будет собирать данные о клиентах принудительно, но возникает вопрос это правомерно, они же нарушают закон о ПД, и будет ли работать 1с если я полностью для этой программы закрою доступ в инет

кто как думает, 1с с версии 8.5.4 будет собирать данные о клиентах принудительно, но возникает вопрос это правомерно, они же нарушают закон о ПД, и будет ли работать 1с если я полностью для этой программы закрою доступ в инет

Apple и Microsoft так уже 100 лет делают

в айфоне телеметрия в Купертино уходит огого какая

Альтернативы нет, для ведения черной бухгалтерии

но 1с софт российский и должен соблюдать законы

Альтернативы нет, для ведения черной бухгалтерии

а crm, erm?, в ней также можно вести учет

коллеги, а вы не путаете ли случаем данные о клиентах с данными клиентов

Ну не начинай

Microsoft вообще приватный ключ от зашифрованного жесткого диска бекапит себе в облако и ничего

а вы знаете какие данные будут утекать им?, и на этот вопрос не кто не скажет, и куда эти данные потом пойдут

на win10

на win10

а что тебе мешает не пользоваться этим продуктом?

Где вас таких гордых линуксоидов штампуют? Нет альтернативы у 1с. Это готовый рынок, бухгалтерша тетя Срака не будет изучать ничего нового в твоей конторе. а просто пойдет в друую, правки под новые формы говноотчетности никто не будет делать

И прочее

а что тебе мешает не пользоваться этим продуктом?

у меня вообще Мак. А речь-то про сбор телеметрии ведем.

Юр, можно подробнее про телеметрию с iPhone в личку?

если выяснится, что данные с 1с будут утикать налево, то от 1с начнут отказываться, нафига такая прога которая будет сливать данные о фирме третьим лицам

если выяснится, что данные с 1с будут утикать налево, то от 1с начнут отказываться, нафига такая прога которая будет сливать данные о фирме третьим лицам

1cbo.ru например, вообще бухгалтерский аутсорсинг.

бухгалтерию ведут фирмы-партнеры 1С.

в общем, непонятно, чем сбор телметрии так пугает.

если, конечно, 1С не пиратская

таких контор сейчас пално, некоторые смотрят на такие конторы с подозрением

а данные клиентов и так в 1С много у кого: backup.1c.ru

Вот чего я не понимаю, так это всяких 1с в облаках

Мне было бы ссыкотно базу заливать

Мне было бы ссыкотно базу заливать

it, как говорится, depends помню, как работал в госучреждении. Так там бухгалтерия такие приколы вытворяла, что лучше б не знать. И в черновиках зарплатной ведомости руководства из столовой пирожки носили (с выпадением листков в лужу, которые нашел безопасник), и провода к мониторам ножницами резали, чтоб скрыть хищения, и даже фальшивого "мальчика из 1С" за компьютер пускали, который данные слил и потом понеслось

слить данные базы 1с не составляет труда, у нас народ доверчивый, я так многих повидал