Серверу проектов davinci resolve не удалось обнаружить на компьютере систему postgresql
Хочу поделиться с вами моим первым успешным опытом восстановления полной работоспособности базы данных Postgres. С СУБД Postgres я познакомился пол года назад, до этого опыта администрирования баз данных у меня не было совсем.
Я работаю полу-DevOps инженером в крупной IT-компании. Наша компания занимается разработкой программного обеспечения для высоконагруженных сервисов, я же отвечаю за работоспособность, сопровождение и деплой. Передо мной поставили стандартную задачу: обновить приложение на одном сервере. Приложение написано на Django, во время обновления выполняются миграции (изменение структуры базы данных), и перед этим процессом мы снимаем полный дамп базы данных через стандартную программу pg_dump на всякий случай.
Во время снятия дампа возникла непредвиденная ошибка (версия Postgres – 9.5):
Ошибка «invalid page in block» говорит о проблемах на уровне файловой системы, что очень нехорошо. На различных форумах предлагали сделать FULL VACUUM с опцией zero_damaged_pages для решения данной проблемы. Что же, попрробеум…
Подготовка к восстановлению
ВНИМАНИЕ! Обязательно сделайте резервную копию Postgres перед любой попыткой восстановить базу данных. Если у вас виртуальная машина, остановите базу данных и сделайте снепшот. Если нет возможности сделать снепшот, остановите базу и скопируйте содержимое каталога Postgres (включая wal-файлы) в надёжное место. Главное в нашем деле – не сделать хуже. Прочтите это.
Поскольку в целом база у меня работала, я ограничился обычным дампом базы данных, но исключил таблицу с повреждёнными данными (опция -T, --exclude-table=TABLE в pg_dump).
Сервер был физическим, снять снепшот было невозможно. Бекап снят, двигаемся дальше.
Проверка файловой системы
В моём случае файловая система с базой данных была примонтирована в «/srv» и тип был ext4.
Останавливаем базу данных: systemctl stop postgresql@9.5-main.service и проверяем, что файловая система никем не используется и её можно отмонтировать с помощью команды lsof:
lsof +D /srv
Мне пришлось ещё остановить базу данных redis, так как она тоже исползовала "/srv". Далее я отмонтировал /srv (umount).
Проверка файловой системы была выполнена с помощью утилиты e2fsck с ключиком -f (Force checking even if filesystem is marked clean):
Далее с помощью утилиты dumpe2fs (sudo dumpe2fs /dev/mapper/gu2--sys-srv | grep checked) можно убедиться, что проверка действительно была произведена:
e2fsck говорит, что проблем на уровне файловой системы ext4 не найдено, а это значит, что можно продолжать попытки восстановить базу данных, а точнее вернуться к vacuum full (само собой, необходимо примонтирвоать файловую систему обратно и запустить базу данных).
Если у вас сервер физический, то обязательно проверьте состояние дисков (через smartctl -a /dev/XXX) либо RAID-контроллера, чтобы убедиться, что проблема не на аппаратном уровне. В моём случае RAID оказался «железный», поэтому я попросил местного админа проверить состояние RAID (сервер был в нескольких сотнях километров от меня). Он сказал, что ошибок нет, а это значит, что мы точно можем начать восстановление.
Попытка 1: zero_damaged_pages
Подключаемся к базе через psql аккаунтом, обладающим правами суперпользователя. Нам нужен именно суперпользователь, т.к. опцию zero_damaged_pages может менять только он. В моём случае это postgres:
psql -h 127.0.0.1 -U postgres -s [database_name]
Опция zero_damaged_pages нужна для того, чтобы проигнорировать ошибки чтения (с сайта postgrespro):
При выявлении повреждённого заголовка страницы Postgres Pro обычно сообщает об ошибке и прерывает текущую транзакцию. Если параметр zero_damaged_pages включён, вместо этого система выдаёт предупреждение, обнуляет повреждённую страницу в памяти и продолжает обработку. Это поведение разрушает данные, а именно все строки в повреждённой странице.
Включаем опцию и пробуем делать full vacuum таблицы:
К сожалению, неудача.
Мы столкнулись с аналогичной ошибкой:
pg_toast – механизм хранения «длинных данных» в Postgres, если они не помещаются в одну страницу (по умолчанию 8кб).
Попытка 2: reindex
Первый совет из гугла не помог. После нескольких минут поиска я нашёл второй совет – сделать reindex повреждённой таблицы. Этот совет я встречал во многих местах, но он не внушал доверия. Сделаем reindex:
reindex завершился без проблем.
Однако это не помогло, VACUUM FULL аварийно завершался с аналогичной ошибкой. Поскольку я привык к неудачам, я стал искать советов в интернете дальше и наткнулся на довольно интересную статью.
Попытка 3: SELECT, LIMIT, OFFSET
В статье выше предлагали посмотреть таблицу построчно и удалить проблемные данные. Для начала необходимо было просмотреть все строки:
В моём случае таблица содержала 1 628 991 строк! По-хорошему необходимо было позаботиться о партициирвоании данных, но это тема для отдельного обсуждения. Была суббота, я запустил вот эту команду в tmux и пошёл спать:
К утру я решил проверить, как обстоят дела. К моему удивлению, я обнаружил, что за 20 часов было просканировано только 2% данных! Ждать 50 дней я не хотел. Очередной полный провал.
Но я не стал сдаваться. Мне стало интересно, почему же сканирование шло так долго. Из документации (опять на postgrespro) я узнал:
OFFSET указывает пропустить указанное число строк, прежде чем начать выдавать строки.
Если указано и OFFSET, и LIMIT, сначала система пропускает OFFSET строк, а затем начинает подсчитывать строки для ограничения LIMIT.
Применяя LIMIT, важно использовать также предложение ORDER BY, чтобы строки результата выдавались в определённом порядке. Иначе будут возвращаться непредсказуемые подмножества строк.
Очевидно, что вышенаписанная команда была ошибочной: во-первых, не было order by, результат мог получиться ошибочным. Во-вторых, Postgres сначала должен был просканировать и пропустить OFFSET-строк, и с возрастанием OFFSET производительность снижалась бы ещё сильнее.
Попытка 4: снять дамп в текстовом виде
Далее мне в голову пришла, казалось бы, гениальная идея: снять дамп в текстовом виде и проанализировать последнюю записанную строку.
Но для начала, ознакомимся со структурой таблицы ws_log_smevlog:
В нашем случае у нас есть столбец «id», который содержал уникальный идентификатор (счётчик) строки. План был такой:
- Начинаем снимать дамп в текстовом виде (в виде sql-команд)
- В определённый момент времени снятия дампа бы прервалось из-за ошибки, но тектовый файл всё равно сохранился бы на диске
- Смотрим конец текстового файла, тем самым мы находим идентификатор (id) последней строки, которая снялась успешно
Снятия дампа, как и ожидалось, прервался с той же самой ошибкой:
Далее через tail я просмотрел конец дампа (tail -5 ./my_dump.dump) обнаружил, что дамп прервался на строке с id 186 525. «Значит, проблема в строке с id 186 526, она битая, её и надо удалить!» – подумал я. Но, сделав запрос в базу данных:
«select * from ws_log_smevlog where обнаружилось, что с этой строкой всё нормально… Строки с индексами 186 530 — 186 540 тоже работали без проблем. Очередная «гениальная идея» провалилась. Позже я понял, почему так произошло: при удалении\изменении данных из таблицы они не удаляются физически, а помечаются как «мёртвые кортежи», далее приходит autovacuum и помечает эти строки удалёнными и разрешает использовать эти строки повторно. Для понимания, если данные в таблице меняются и включён autovacuum, то они не хранятся последовательно.
Попытка 5: SELECT, FROM, WHERE > Неудачи делают нас сильнее. Не стоит никогда сдаваться, нужно идти до конца и верить в себя и свои возможности. Поэтому я решил попробовать ешё один вариант: просто просмотреть все записи в базе данных по одному. Зная структуру моей таблицы (см. выше), у нас есть поле id, которое является уникальным (первичным ключом). В таблице у нас 1 628 991 строк и id идут по порядку, а это значит, что мы можем просто перербрать их по одному:
Если кто не понимает, команда работает следующим образом: просматривает построчно таблицу и отправляет stdout в /dev/null, но если команда SELECT проваливается, то выводится текст ошибки (stderr отправляется в консоль) и выводится строка, содержащая ошибку (благодаря ||, которая означает, что у select возникли проблемы (код возврата команды не 0)).
Мне повезло, у меня были созданы индексы по полю id:
А это значит, что нахождение строки с нужным id не должен занимать много времени. В теории должно сработать. Что же, запускаем команду в tmux и идём спать.
К утру я обнаружил, что просмотрено около 90 000 записей, что составляет чуть более 5%. Отличный результат, если сравнивать с предыдущим способом (2%)! Но ждать 20 дней не хотелось…
Попытка 6: SELECT, FROM, WHERE id >= and id
У заказчика под БД был выделен отличный сервер: двухпроцессорный Intel Xeon E5-2697 v2, в нашем расположении было целых 48 потоков! Нагрузка на сервере была средняя, мы без особых проблем могли забрать около 20-ти потоков. Оперативной памяти тоже было достаточно: аж 384 гигабайт!
Поэтому команду нужно было распараллелить:
Тут можно было написать красивый и элегантный скрипт, но я выбрал наиболее быстрый способ распараллеливания: разбить диапазон 0-1628991 вручную на интервалы по 100 000 записей и запустить отдельно 16 команд вида:
Но это не всё. По идее, подключение к базе данных тоже отнимает какое-то время и системные ресурсы. Подключать 1 628 991 было не очень разумно, согласитесь. Поэтому давайте при одном подключении извлекать 1000 строк вместо одной. В итоге команда преобразилоась в это:
Открываем 16 окон в сессии tmux и запускаем команды:
Через день я получил первые результаты! А именно (значения XXX и ZZZ уже не сохранились):
Это значит, что у нас три строки содержат ошибку. id первой и второй проблемной записи находились между 829 000 и 830 000, id третьей – между 146 000 и 147 000. Далее нам предстояло просто найти точное значение id проблемных записей. Для этого просматриваем наш диапазон с проблемными записями с шагом 1 и идентифицируем id:
Счастливый финал
Мы нашли проблемные строки. Заходим в базу через psql и пробуем их удалить:
К моему удивлению, записи удалились без каких-либо проблем даже без опции zero_damaged_pages.
Затем я подключился к базе, сделал VACUUM FULL (думаю делать было необязательно), и, наконец, успешно снял бекап с помощью pg_dump. Дамп снялся без каких либо ошибок! Проблему удалось решить таким вот тупейшим способом. Радости не было предела, после стольких неудач удалось найти решение!
Благодарности и заключение
Вот такой получился мой первый опыт восстановления реальной базы данных Postgres. Этот опыт я запомню надолго.
Ну и напоследок, хотел бы сказать спасибо компании PostgresPro за переведённую документацию на русский язык и за полностью бесплатные online-курсы, которые очень сильно помогли во время анализа проблемы.
Может кто внятно объяснить почему DaVinci запускается только из под администратора ? Где это написано, покажите пожалуйста или это глюк системы?
Aleksej Shirnov, У редакторов всегда должны быть расширенные права. Неужели сложно создать другую учётку с нужными правами
Aleksej, Я думаю, потому что Давинчи работает с сетевыми базам данных. Поэтому админ нужен, чтобы не плясать с бубном прописывая полномочия для пользователя
Артур Мальцев, Какой точно номер давинчи?, если что они все беты пока. Последняя 16.1 версия. Переустановите с полным удалением, удалите все папки Давинчи, особенно в program data, там могут оставаться настройки от прошлых версий. Почистите реестр с помощью утилиты CCleaner. Когда будете утанавливать новую версию снимите галочку с установки resolve panels, это дополнительное ПО для консолей Blackmagic. Если его у вас нет то и ставить его не нужно. На всякий случай переустановите драйвер видеокарты чистой установкой, на этой неделе как раз вышло новое обновление. Запускайте первый раз от имени администратора. Возможно первые пару раз загрузка может стопарится, просто сканируется многие параметры и всё зависит от установленных плагинов и других обстоятельств. Поэтому следите за окном приветсвия, на каком моменте застопорится, подождите 3-8 минут. Потом можно остановить релактор в диспетчере задач и запустить снова.
Доброй ночи ребят, программа не запускается совсем. Не пишет никаких ошибок и ничего подобного, зато еЁ видно в диспечере, комп был перезагружен неоднократно. Что можно сделать (((
Дима, установить 10 версию винды, брать на офф сайте образ ОС и потом ставить давинчи. Понимаете что система может быть сильно захламлена. За последние 6 лет ни разу проблем не испытывал с чистой ОС.
So I've been trying to set up a postgres server using davinci resolve, but every time I try to create the server, it gives me a message saying:
"failed to connect to the database server as the connection was refused. Please ensure that the database server is configured to allow connections from this device."
Do I need a server set up already to use the feature in davinci? Is there any advice for setting one up if so?
If pc specs are important:
XFX RX 580 Black edition (XXX I think as well)
Corsair Vengeance 16GB DDR4 @ 3200MHz CL16
Asus ROG 450-F gaming
Samsung 980 SSD
WD Black 640GB HDD
Kingston A400S 240GB (C drive)
Running off of ethernet connection
Davinci Resolve 17 free
edit*: added what version of davinci im running
Welcome to r/davinciresolve! If you're brand new to Resolve, please make sure to check out the free official training, the subreddit's wiki and our weekly FAQ Fridays. Your question may have already been answered.
If you can't find a solution, please make sure you include the following information. Edit your post (or leave a top-level comment) if you haven't included this information.
Once your question has been answered, change the flair to "Solved" so other people can reference the thread if they've got similar issues.
Thanks! -Automod on behalf of the mod team
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
One important question first: why do you need (or want) a Postgres server? Will you be using multiple systems? Collaboration? A render farm? Just for fun? As a learning experience? Ease of database backups? Something for a NAS to do other than store files?
For many people on this subreddit, a disk database will suit their needs just fine. If you're in a DI/Finishing (color correction) facility or something similar with multiple artists working on the same project(s), then a Postgres project database server is the way to go. Maintaining it and making it smooth can take a lot of work, especially if you're collaborating remotely.
Now to the troubleshooting/building:
The short answer is yes, you need the server to be set up before you can connect to it. This can be the localhost (127.0.0.1) or another system on your network (or VPN).
Beginning with 17, there's a separate installer for the server on the support page (linked as "Download Resolve" at the top of the sub. That'll install the version of Postgres Resolve uses and a GUI for the project server for Windows or macOS. BMD doesn't have a Linux version of the project server, but this (older) guide for setting up a centOS Resolve Project Server may be a good place to start. (Seth's one of the Linux gurus when it comes to Resolve, and BMD even recommends some of his documentation for setting up a Linux Resolve system)
I'm crashing for the night, so I'm gonna stop here for now, but if I had to give a tl;dr:
tl;dr - Yes, there needs to be a (running) server to connect to. Maintaining it's a bit of a chore and may not be worth it if you're only using one system and/or aren't familiar with basic network/sysadmin stuff
Ищете решение проблемы Davinci Resolve не открывает? Если ваш Resolve вообще не отвечает, вы можете попробовать следующие методы, чтобы немедленно решить проблему.
Ищем решение проблемы DaVinci Resolve не открывается проблема? Независимо от того, что ваш Resolve вообще не отвечает или зависает на экране загрузки, вы можете попробовать следующие методы, чтобы немедленно решить проблему.
Попробуйте эти исправления
Первое, что вы должны попробовать, это завершить процесс DaVinci Resolve в диспетчере задач. Вот как:
1) Нажмите Ctrl + Shift + Удалить чтобы открыть Диспетчер задач.
2) Найдите любой процесс, связанный с Revolve.
3) Щелкните правой кнопкой мыши и выберите Завершить задачу .
Теперь вы принудительно отключили Davinci Resolve. Запустите программу еще раз, и вы сможете открыть ее без проблем.
Не повезло? Не беспокойтесь. У нас есть еще несколько исправлений для вас.
Исправление 5. Увеличьте виртуальную память
Если в вашей системе недостаточно виртуальной памяти, Windows увеличивает размер файла подкачки виртуальной памяти. Во время этого процесса запросы памяти для некоторых приложений могут быть отклонены, например, DaVinci Resolve. Чтобы облегчить это, вы можете вручную увеличить размер файла подкачки.
- На клавиатуре нажмите кнопку Окна ключ с логотипом + р клавишу одновременно и введите sysdm.cpl чтобы открыть системные настройки.
- Перейти к Передовой вкладку и выберите Настройки под Представление .
- Когда откроется окно «Параметры производительности», перейдите к Передовой вкладку и выберите Изменять .
- Снимите флажок Автоматически управлять размером файла подкачки для всех дисков . Затем выберите Обычный размер и введите соответствующее значение.
Примечание: Рекомендуется использовать номер, который полтора раза общая доступная память для Начальный размер и три раза доступной памяти для Максимальный размер когда возможно. (Например, моя установленная оперативная память составляет 16 ГБ, поэтому я установил начальный размер 24 000, максимальный размер — 48 000). Если вы не знаете свою установленную оперативную память, вы можете нажать кнопку Окна ключ + Пауза чтобы проверить характеристики вашего устройства. - Нажмите В ПОРЯДКЕ чтобы подтвердить изменение.
Перезагрузите компьютер, чтобы изменения вступили в силу, и попробуйте открыть DaVinci Resolve, чтобы проверить, успешно ли он запускается.
Исправление 9. Переустановите DaVinci Resolve
Если ни одно из приведенных выше исправлений не решило вашу проблему с открытием Resolve, вы можете полностью переустановить свою программу и удалить все файлы ( C:Program FilesBlackmagic DesignDaVinci Resolve ) осталось позади.
Этот пост помог вам избавиться от проблемы? Не стесняйтесь, напишите нам, если у вас есть какие-либо вопросы или предложения.
Исправление 6. Включить мультимонитор IGPU в BIOS
Многие пользователи сообщают, что функция IGPU Multi-Monitor может повлиять на использование DaVinci Resolve, из-за чего Resolve не открывается. Чтобы включить эту функцию, вы должны перезагрузить компьютер и войти в BIOS.
- Перезагрузите компьютер и продолжайте нажимать клавишу настройки (показана выше), как только вы увидите логотип производителя на экране, чтобы войти в настройки BIOS.
- Под Передовой настройки, вы увидите Опция мультимонитора IGPU .
- Переключите эту функцию с Неполноценный к Включено .
- Сохраните и выйдите из BIOS.
Известно, что антивирусное программное обеспечение мешает работе многих программ, и если у вас возникли проблемы с Resolve после установки стороннего антивирусного программного обеспечения, вам может потребоваться их удалить, поскольку их отключения недостаточно для предотвращения их работы в фоновом режиме.
А пока вам следует отключить VPN-сервисы, такие как NordVPN, ExpressVPN.
Если DaVinci Resolve не запускается после удаления антивирусного программного обеспечения и отключения VPN, вы можете попробовать следующее исправление, указанное ниже.
Исправление 4. Обновите графический драйвер
Редактирование видео с помощью этого DaVinci Resolve требует больших ресурсов графического процессора, поэтому обязательно обновляйте драйверы графического процессора (а иногда и аудиодрайверы).
Вы можете обновить графический драйвер вручную, посетив веб-сайт производителя ( NVIDIA / AMD ), найти последнюю правильную программу установки и выполнить пошаговую установку. Но если у вас нет времени или терпения на установку вручную, вы можете сделать это автоматически с помощью Драйвер Легкий .
Driver Easy автоматически распознает вашу систему и найдет правильные драйверы для ваших видеокарт и версии Windows, а также загрузит и установит их правильно:
После обновления драйверов перезагрузите компьютер и запустите Resolve, чтобы проверить, решена ли проблема.
Исправление 2. Отключите USB-устройства
Согласно тому, что предположили многие пользователи Resolve, USB-устройства могут привести к тому, что ваш Resolve не откроется, поэтому вы можете отключить эти устройства, чтобы проверить, работает ли ваш Resolve снова.
Resolve сработает, особенно если вы используете USB-гарнитуру в качестве устройства вывода звука. После того, как вы удалили USB-устройство с вашего ПК, снова запустите Revolve.
Исправление 3. Запустите DaVinci Resolve в режиме совместимости
Все еще не можете запустить Resolve? Это может быть вызвано некоторыми проблемами несовместимости, которые можно решить, запустив Resolve в режиме совместимости.
Теперь вы можете запустить Resolve, чтобы проверить проблему. Если DaVinci Resolve по-прежнему не отвечает, вы можете перейти к следующему исправлению ниже.
Исправление 8. Разрешить доступ к сетевому порту TCP
Другая причина, по которой ваш DaVinci Resolve не отвечает, заключается в том, что у него нет доступа к вашим TCP-портам, что необходимо для успешного запуска вашего DaVinci Resolve.
Вот как быстро решить эту проблему:
- На клавиатуре одновременно нажмите клавиши Windows + R и введите пауэршелл .
- Введите следующую командную строку:
Get-NetTCPConnection | Where-Object < $_.State -eq Listen -and $_.LocalPort -eq 1144 >| ForEach-Object - Если в следующей записи ничего не появляется, с вашей TCP-сетью все в порядке. Но если это так, вам, возможно, придется связаться с Блэкмагик Дизайн службу поддержки с файлом журнала.
- Перейдите к C:Program FilesBlackmagic DesignDaVinci Resolve .
- Дважды щелкните по CaptureLogs.bat файл (или щелкните правой кнопкой мыши, а затем запустите от имени администратора).
- Это создаст журнальный файл на рабочий стол – Журналы DaVinci-Resolve-.zip .
Читайте также: