Ошибка не удалось увеличить файл base
restore.conf должен сразу быть настроен и положен в дата директорию, поскольку без него база при запуске ругнется, что не хватает файлов и упадет (еще может говорить, что нужно удалить backup_label, что делать не нужно). При верном restore.conf PostgreSQL начнет подчитывать с основной базы wal-файлы и будет работать в режиме восстановления.
Thu, 03 Apr 2014 11:44:21 +0400 от Николай Богданов <>:
День добрый. Использую Continuous Archiving для бэкапов и столкнулся с
проблемой.
После SELECT pg_start_backup('pgbackup', true); начинаю копирование
данных, в это же время postgres решает очистить несколько файлов. В
результате имею неконсистентный бэкап. И при этом, когда бэкап
разворачивается postgres даже не скажет, что файлов не хватает. Только
потом уже можно узнать, получив приблизительно такую ошибку.
ОШИБКА: не удалось открыть файл "base/16420/32858809": No such file or
directory
Сейчас я делаю сначала копию rsync, и смотрю на его код возврата. В
случае кода, отличного от 0, я перекачиваю еще раз. Это неудобно. Можно
ли вообще как-то избежать данной проблемы? Не связана ли она с autovacuum?
День добрый. Использую Continuous Archiving для бэкапов и столкнулся с проблемой.
После SELECT pg_start_backup('pgbackup', true); начинаю копирование данных, в это же время postgres решает очистить несколько файлов. В результате имею неконсистентный бэкап.
Вы где-то ошиблись и что-то делаете не правильно, или копирование WAL или их применение при разворачивании.
pg_start_backup и последующее применение всех WAL сгенерированных с начала pg_start_backup до pg_stop_backup
к копии при разворачивании бекапа гарантируют консистентность, независимо от того, какие файлы там создавались
2014-04-03 11:44 GMT+04:00 Николай Богданов > :
День добрый. Использую Continuous Archiving для бэкапов и столкнулся с проблемой.
После SELECT pg_start_backup('pgbackup', true); начинаю копирование данных, в это же время postgres решает очистить несколько файлов. В результате имею неконсистентный бэкап.
Вы где-то ошиблись и что-то делаете не правильно, или копирование WAL или их применение при разворачивании.
pg_start_backup и последующее применение всех WAL сгенерированных с начала pg_start_backup до pg_stop_backup
к копии при разворачивании бекапа гарантируют консистентность, независимо от того, какие файлы там создавались
Сергей, я наверное неверно выразился. С WAL-файлами проблем нет. Проблемы с файлами страниц внутри кластера. Вот кусочек лога сегодняшнего бэкапа.
+ ssh /opt/scripts/start_backup.sh
pg_start_backup
-----------------
14E1/6D000020
(1 строка)
+ rsyncload -a -v --bwlimit=100000 --exclude=pg_xlog --exclude=pg_log --exclude=server.crt --exclude=server.key --exclude=/var/lib/postgresql/9.2/main/server.key rsync://10.0.0.2/root//var/lib/postgresql/9.2/main/ /var/tmp/db
---skip---
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204170" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204171" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204172" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204173" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204174" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204174_fsm" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204175" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204176" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204177" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204178" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204179" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204180" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204181" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204182" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204183" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204184" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204185" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204186" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204187" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204188" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204189" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204190" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204191" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204192" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204193" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204194" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204195" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204196" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204197" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204198" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204199" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204200" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204201" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204202" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204203" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204204" (in root)
file has vanished: "/var/lib/postgresql/9.2/main/base/16420/33204205" (in root)
---skip---
rsync warning: some files vanished before they could be transferred (code 24) at main.c(1536) [generator=3.0.9]
+ export e=24
+ e=24
То есть после pg_start_backup у меня сам postgres очистил несколько файликов. После чего я сказал pg_stop_backup и начал восстанавление.
Восстановление базы прошло без проблем, но при определенных запросах база выдает, что не может найти файл.
Тут много причин может быть, их подробно разбирали в разделе ноуткедди, плюс есть куча мануалов по постгре. Для начала попробуй следующий сценарий:
1. Полный бекап базы из хм2.
2. Полное удаление существующей базы в хм2.
3. Отключение всех видов логов в конфиге постгре. А еще лучше обновить постгре плюс прописать в конфиг все рекомендуемые оптимизации.
4. Пообновлять все что можно из софта, включая виндовс и все системное.
5. Создать новую базу в хм2 из бекапа.
6. Сделать полный ресет нотсов в ноуткедди.
Если номер 1 не получится, значит база порченная, но это еще не приговор, есть сценарии лечения и для этого случая.
Кроме того, что бы полный вакуум постгре в принципе мог произойти, на разделе с базой должно быть свободного места столько же, сколько вся база сама весит, или хотя бы не намного меньше (а лучше больше, что бы знать что косяк точно не сдесь). Иначе полный вакуум произойти не сможет, а частичный вакуум может и не помочь вовсе.
Раздулась база
[SPOILER]ИНФОРМАЦИЯ: очистка "public.handhistories" ОШИБКА: не удалось увеличить файл "base/16392/169717551.9": No space left on device HINT: Проверьте, есть ли место на диске. ОШИБКА: не удалось увеличить файл "base/16392/169717551.9": No space left on device HINT: Проверьте, есть ли место на диске.[/SPOILER]
Таким образом объем базы не уменьшается. И продолжает весить ОЧЕНЬ много.
Подскажите, пожалуйста, что можно предпринять?
Пользуюсь НотеКадди. Как раз после очередного блока нотсов база и раздулась.
П.С. Всё обслуживание базы делал с помощью PGAdmin III, не в самом ХМ2.
Пользуюсь PostgreSQL 9.0
Сейчас появились новые особенности. Около двух недель импорт и последущая запись нотсов проходила нормально в стандартном режиме. Но сегодня опять сожрало всё оставшееся свободное место(Более 10Гб).
В поисках этих самых файлов, которые занимают всё место наткнулся на такую картину:
И вот таких файлов с одним и тем же именем только в этом случае набралось 173 шт. Также существуют менее объемные файлы, которых набралось 22 шт. с одним именем.
Можно ли что-нибудь сделать? Кроме сноса базы?
Спасибо.
Тут много причин может быть, их подробно разбирали в разделе ноуткедди, плюс есть куча мануалов по постгре. Для начала попробуй следующий сценарий:
1. Полный бекап базы из хм2.
2. Полное удаление существующей базы в хм2.
3. Отключение всех видов логов в конфиге постгре. А еще лучше обновить постгре плюс прописать в конфиг все рекомендуемые оптимизации.
4. Пообновлять все что можно из софта, включая виндовс и все системное.
5. Создать новую базу в хм2 из бекапа.
6. Сделать полный ресет нотсов в ноуткедди.
Если номер 1 не получится, значит база порченная, но это еще не приговор, есть сценарии лечения и для этого случая.
Кроме того, что бы полный вакуум постгре в принципе мог произойти, на разделе с базой должно быть свободного места столько же, сколько вся база сама весит, или хотя бы не намного меньше (а лучше больше, что бы знать что косяк точно не сдесь). Иначе полный вакуум произойти не сможет, а частичный вакуум может и не помочь вовсе.
A) Вот это "1 048. " есть максимальный размер файла, разрешенного в Postgres. Потому их и столько с одинаковым именем, что в один не поместилось.
А там внутри - почти наверняка именно нотсы Caddy.
Кстати, функция HM backup тоже будет класть промежуточные результаты работы (а их много образуется, пока процесс не завершится) в ту же TEMP - так что вполне возможно, что и бекап-то не доделается.
Общее правило: для работы HM backup места в папке TEMP должно быть раза в четыре больше, чем размер БД.
Можно попробовать ее перенести на другой диск - Гугл даст полмиллиона ссылок на (одинаковые) инструкции, как это делается. Там просто.
Тут дело вот в чем: практически все программы, сделанные под Виндовс, в качестве временного хранилища используют системную папку TEMP (или TMP) - и postgres исключением не является.
По умолчанию она расположена в папке профиля пользователя Винды, под которого загружена система. А папка профиля - на системном диске. %localappdata%\Temp
Теоретически программы должны сами же и убирать за собой в TEMP - но иногда не срабатывает. Особенно при аварийных завершениях и т.п.
Места свободного должно быть раза в два больше, чем объем базы данных.
Что можно сделать:
- если диск на компе один, сначала просто почисти TEMP - возможно, этого бует достаточно. Причем в Виндовс есть средство для этого: Свойства диска - очистка диска.
- если дисков больше одного, можно рассмотреть вариант с перемещением папки TEMP на другой.
Массу ссылок на одинаковую инстркуцию как сделать, покажет Гугл по такому запросу
как перенести папку TEMP пользователя под windows 7
Получилось перенести папку темп на на другой физический диск но толку это не прибавило. Рылся долго нашел сам случайно наткнулся когда проходи вакумизация в БД создаеться клоный файлов с большим размером и менно из за них не происходит вакумизация а в папке темп ничего не происходит. Файлы создаються большого размера вопрос такой как сделать что бы эти новые файлы либо в темп записывались либо в другое место при этом не перенося БД?
102621
Спасибо большое за совет все сработало. Создал новое Tablespace на другом диске туда перекинул таблицу с ноусами вакумизировал ее и обратно закину. Еще раз спасибо за помощь.
Вопрос: таблицу и я могу перекинуть. А ты пытался ВСЮ базу данных одним кликом вот так на другой tablespace задвинуть? У меня не получилось, только по одной табличке за раз, а это утомительно.
Вопрос: таблицу и я могу перекинуть. А ты пытался ВСЮ базу данных одним кликом вот так на другой tablespace задвинуть? У меня не получилось, только по одной табличке за раз, а это утомительно.
Я нашел в табличных пространствах таблицу отвечающие за ноутсы он онказалась весом 149гб(она как и оказалось сожрала всю памать) ну ее собственно и перекинул на другой тейбл спейс а вакумизация идет по все базе не зависимо от раположения тейбелспейса.
Это-то понятно.
просто я задался идеей найти отличный от описанного в нашем FAQ (и более простой) способ быстро передвигать ВСЮ базу - а одним кликом это не получается почему-то.
Хотя. на самом деле, если переместить на другой tablespace вот только эти таблицы - это почти 95% суммарного объема
compliedplyerresults
handhistories
notecaddy_data (if)
players
pokerhands
tourneydata
tourneysummaries
Раздулась база
[SPOILER]ИНФОРМАЦИЯ: очистка "public.handhistories" ОШИБКА: не удалось увеличить файл "base/16392/169717551.9": No space left on device HINT: Проверьте, есть ли место на диске. ОШИБКА: не удалось увеличить файл "base/16392/169717551.9": No space left on device HINT: Проверьте, есть ли место на диске.[/SPOILER]
Таким образом объем базы не уменьшается. И продолжает весить ОЧЕНЬ много.
Подскажите, пожалуйста, что можно предпринять?
Пользуюсь НотеКадди. Как раз после очередного блока нотсов база и раздулась.
П.С. Всё обслуживание базы делал с помощью PGAdmin III, не в самом ХМ2.
Пользуюсь PostgreSQL 9.0
Сейчас появились новые особенности. Около двух недель импорт и последущая запись нотсов проходила нормально в стандартном режиме. Но сегодня опять сожрало всё оставшееся свободное место(Более 10Гб).
В поисках этих самых файлов, которые занимают всё место наткнулся на такую картину:
И вот таких файлов с одним и тем же именем только в этом случае набралось 173 шт. Также существуют менее объемные файлы, которых набралось 22 шт. с одним именем.
Можно ли что-нибудь сделать? Кроме сноса базы?
Спасибо.
A) Вот это "1 048. " есть максимальный размер файла, разрешенного в Postgres. Потому их и столько с одинаковым именем, что в один не поместилось.
А там внутри - почти наверняка именно нотсы Caddy.
Кстати, функция HM backup тоже будет класть промежуточные результаты работы (а их много образуется, пока процесс не завершится) в ту же TEMP - так что вполне возможно, что и бекап-то не доделается.
Общее правило: для работы HM backup места в папке TEMP должно быть раза в четыре больше, чем размер БД.
Можно попробовать ее перенести на другой диск - Гугл даст полмиллиона ссылок на (одинаковые) инструкции, как это делается. Там просто.
Что делать, если архив базы загружается в файловом варианте с ошибкой "Превышен максимально допустимый размер внутреннего файла", а загрузить очень надо? Постараюсь примерно описать технологию, которую нам удалось разработать при активном участии Виктора Сосновского из фирмы "1С" на партнерском форуме.
Предположим, вы сформировали архив базы и теперь пытаетесь загрузить его в файловом варианте. Сначала все идет хорошо, но в какой-то момент возникает ошибка:
"Ошибка загрузки информационной базы. В информационную базу загружены не все данные по причине: Ошибка СУБД: Превышен максимально допустимый размер внутреннего файла 'D:\1CBASES\NewDB/1Cv8.1CD' "
Я лично потратил ОЧЕНЬ много времени на поиск решения этой проблемы и в итоге нашел его, что позволило нам создать файловую копию базы данных размером 18 Гб и в итоге сэкономило примерно неделю времени (могу в комментариях рассказать, как было дело, но сейчас речь не о том).
Итак, причин возникновения такой ошибки может быть несколько:
- Размер КАКОЙ-ЛИБО таблицы в базе данных превышает лимит для файловой версии (4 Гб). Если честно, во избежание подобных эксцессов мы проверяли размеры таблиц базы заранее с помощью обработки "SQL базомер" (или аналогов).
- Ошибка связана с глюком особенностями платформы, и вызвана определенной спецификой структуры метаданных выгружаемой конфигурации.
С первым случаем все понятно - если базомер показал превышение лимита по каким-то из таблиц базы, то эти таблицы необходимо почистить. Если речь идет о справочнике или непериодическом регистре сведений, то нужно постараться удалить оттуда ненужные элементы/записи. То же самое относится и к "тяжелым" документам с их табличными частями. В первую очередь следует заняться удалением помеченных объектов, конечно.
Регистры накопления - отдельная тема. Размеры таблиц итогов могут превышать размеры таблиц записей регистра, причем зачастую значительно. Иногда может помочь даже простой пересчет итогов.
Регистры остатков могут некорректно (не по всем измерениям) закрываться, что приводит к ОЧЕНЬ значительному и быстрому разрастанию таблиц итогов. Списание "зависших" остатков регистра накопления может при последующем пересчете итогов дать экономию до нескольких Гб, проверено на собственном опыте у "нерадивых" клиентов. ))
Что же делать, если каждая таблица вашей базы размером менее 4 Гб, но ошибка все равно возникает?
Это значит, что у вас второй случай - проблемная структура метаданных конфигурации. Вероятнее всего, ошибка возникает на этапе создания индексов.
В двух словах опишу ситуацию в целом, чтобы было понятно, словами Виктора Сосновского из 1С. Ниже цитата с партнерского форума:
"При загрузке информационной базы в файловом варианте сначала загружаются данные всех таблиц, а затем создаются индексы. Ошибка создания индекса приводит к тому, что индекс, созданный с ошибкой, и все последующие индексы не создаются. Если в базе много данных, то это приведет к существенному снижению производительности. Полноценная работа с такой базой будет невозможна."
Нужно узнать, какая именно таблица приводит к ошибке при создании индекса.
Включаем технологический журнал - в папку "С:\Program Files (x86)\1cv82\__НомерВерсииПлатформы__\bin\conf\" (или аналогичную, __НомерВерсииПлатформы__ подставьте свой) кладем файл logcfg.xml примерно следующего содержания:
Внимательно следим за тем, чтобы каталоги для дампов и логов:
- Существовали
- Различались
- Были доступны для чтения и записи тому пользователю Windows, от лица которого вы запускаете конфигуратор.
Перезапускаем конфигуратор (при этом включается технологический журнал) и заново пробуем загрузить наш .DT. После возникновения ошибки идем в каталог для логов, находим там файл лога, содержащий нашу ошибку, и внимательно читаем его.
Первое же вхождение EXCPCNTX в логе в моем случае указало на команду, которая вызвала ошибку: CREATE INDEX _Accum27148_ByDims_TRRRRRRRRRSSR (у вас название индекса будет другое).
По цифрам из названия индекса с помощью обработки "Структура хранения таблиц базы данных" (или аналогов, которые умеют показывать индексы) находим, какой таблице принадлежит данный индекс. У меня это оказалась таблица оборотов одного из нетиповых регистров накопления.
А дальше начинается самое интересное - нужно попытаться угадать, что именно в структуре вашей таблицы приводит к ошибке индексации.
В первую очередь следует смотреть, какие поля входят в индекс. Как выяснилось, платформа ОЧЕНЬ не любит, когда совокупный размер ключевых полей индекса становится значительным. В частности, она не любит индексировать длинные строки - так, в моем случае в индекс попадало измерение с типом СТРОКА (500) и оно вызывало ошибку. Другой представитель фирмы "1С" высказался на партнерском форуме еще в 2007 году:
" Если длина ключа оказывается близкой к 2К, то начинается резкий рост размера индексов с рядом неприятных последствий. "
И действительно, в 2013 году ничего не изменилось - в подобных случаях наблюдается лавинообразный рост размеров индекса на файловой базе. А когда таблица индекса превышает лимит в 4 Гб, загрузка .DT останавливается с ошибкой.
Лично мне помогло отключить для проблемного измерения флажок "Использование в итогах", т.к. в реальности итоги по нему не требовались. Оно перестало попадать в саму таблицу оборотов и, как следствие, в индекс таблицы оборотов. Есть и другие способы - более строго ограничить размер строки, например. Читал, что некоторым это помогало.
Эти изменения необходимо применить к информационной базе, при этом произойдет реструктуризация вашей таблицы.
Если изменения внесены на SQL-копии базы, то после этого нужно заново выгрузить .DT и попытаться перезагрузить его в файловой версии.
Кому особо не повезло и ошибка вылезла снова - тому следует повторить сначала всю процедуру, начиная с анализа логов. Возможно, проблемная таблица была не одна, или вам не удалось решить проблему с размерами полей, входящих в индекс.
Читайте также: