Задать вопрос
Melkij

Melkij

DBA для вашего PostgreSQL?
Комментарии

  • Как переподключить LVM-диск к другой ВМ?

    Melkij
    @Melkij
    PV-диски как подключаются?

    по UUID в заголовке PV. Какие в системе есть PV - сканируются все диски системы и их разделы, имена без разницы.

    подключайте остальные PV, пока не снимете флаг (p)artial.
    Написано

  • Как переподключить LVM-диск к другой ВМ?

    Melkij
    @Melkij
    а где вы в lvm вообще нашли sdh или sdb? lvm стартует со сканирования всех доступных дисков и партиций, дальше собирается по найденным метаданным. Буквы дисков ему без разницы, lvm делался во времена когда /dev/sda вообще не существовало.

    Для получения осмысленного состояния lv, конечно, нужны одновременно все части pv, на которых lv была размещена. Ну, если данные нужны.
    Написано

  • Почему не добавляет данные в базу данных на laravel 13 и не перенаправляет на другую страницу?

    Melkij
    @Melkij
    я вероятно не помню уже laravel достаточно хорошо, но где какой-нибудь вход в BasicController::submit?
    может быть должно быть
    Route::post('/contact', [BasicController::class, 'submit'])->name('contact.post');
    Написано

  • Postgres выдаёт unknown для типа char - в чём ошибка?

    Melkij
    @Melkij
    ERROR: function testfunc3(
    1: select testboris3(

    Кому верить? Пожалуй, никому: вы, вероятно, поменяли текст цитаты в вопросе.

    сделайте самодостаточный тест. Вот такой create function, вот так вызывается и вот такая ошибка. Дополнить листингом \df имя_функции чтобы проверить на возможные остатки от прошлых экспериментов. Может существовать несколько одноимённых функций с разными наборами аргументов (в этом случае, правда, текст ошибки будет более явно намекать на невозможность выбрать конкретную функцию)
    Написано

  • Почему не создается логическая репликация на Windows 10 и падает воркер?

    Melkij
    @Melkij
    025-11-18 14:39:19.442 MSK [12692] СООБЩЕНИЕ: процесс синхронизации таблицы при логической репликации для подписки "im_sub", таблицы "link_accessories" запущен
    2025-11-18 14:39:19.442 MSK [12692] ОТЛАДКА: connecting to publisher using connection string "dbname=op_market_integration host=localhost port=5432 user=postgres password=postgres"
    2025-11-18 14:39:37.447 MSK [12692] ОШИБКА: ошибка при чтении результата команды передачи:

    А говорите нет ошибки помимо того что воркер завершился.
    error reading result of streaming command если говорить обычным языком. Забавно что PQerrorMessage не смог добавить деталей
    Что в логах публикации в это время?
    Написано

  • Специалисты по управлению качеством в IT-компаниях есть?

    Melkij
    @Melkij
    Если бы завод мог исправить дефект во всей выпущенной (и проданной) продукции деплоем обновления за 15 минут с нулевыми расходами - там бы тоже не осталось специалистов по управлению качеством...
    Написано

  • VACUUM в PostgreSQL 15 уже несколько суток в фазе vacuuming indexes что можно сделать?

    Melkij
    @Melkij
    хммм, сходу не помню, надо в исходниках проверить...
    https://github.com/postgres/postgres/blob/REL_17_6...
    вот у нас all visible биты в visibility map пишутся, во время стадии PROGRESS_VACUUM_PHASE_VACUUM_HEAP по мере прохождения по heap_blks_vacuumed обновляем страницы и вместе с этим по каждой странице проверяем, не надо ли поставить visibility map биты
    Написано

  • VACUUM в PostgreSQL 15 уже несколько суток в фазе vacuuming indexes что можно сделать?

    Melkij
    @Melkij
    bsd9, тут же, на этом же этапе перед чтением блока консультируемся у visibility map, вдруг блок можно пропустить и если это возможно.
    Написано

  • VACUUM в PostgreSQL 15 уже несколько суток в фазе vacuuming indexes что можно сделать?

    Melkij
    @Melkij
    да, нужно будет прервать.
    vacuum штука цикличная:
    - читаем табличку последовательно от 0 блока
    - hot pruning и чего-то ещё меняется и записывается сразу по мере чтения
    - при этом накапливаем в массиве CTID строк, которые хотим вычистить (heap_blks_scanned)
    - если на следующем блоке можем превысить допустимый размер нашего массива CTID - то запускаем vacuuming indexes, в котором читаем все индексы и удаляем из них CTID из нашего массива
    - вычищаем из куска таблицы, которую за эту итерацию прошли, все эти CTID
    - heap_blks_vacuumed доходит до heap_blks_scanned и продолжаем читать с того места где прервались на vacuuming indexes.

    соответственно, прервать вакуум можно в любой момент, но обидно если это происходит перед vacuuming heap - тяжёлую часть по большей части выполнили, а сохраниться не успели. При следующем запуске vacuum будем жевать те же самые CTID ещё раз.
    С другой стороны, если в таблице появилось дохлых CTID на 10 проходов через vacuuming indexes и мы уже сделали index_vacuum_count = 5, то вот эти сделанные index_vacuum_count уже сохранены. Если тут прибить вакуум, то следующий вакуум уже не увидит множество мёртвых строк в начале таблицы и быстро дойдёт до того места, откуда начиналась прерванная 6 итерация.
    Написано

  • VACUUM в PostgreSQL 15 уже несколько суток в фазе vacuuming indexes что можно сделать?

    Melkij
    @Melkij
    А что вы в таких ситуация предпринимаете? Или остается только ждать?

    начальный реиндекс если есть показания к нему
    Дальше запустить вакуум и не мешать ему работать. Поглядывать за wraparound. Если грозит - тогда index_cleanup = off чтобы отодвинуть горизонт и затем дать вакууму работать дальше над индексами.
    Может быть смысл в pg_repack, если обстоятельства позволяют.
    Написано

  • Почему увеличилась генерация WAL-сегментов?

    Melkij
    @Melkij
    Есть такая штука как full page image (FPI) - при первом изменении страницы после чекпойнта записывается в WAL копия всей страницы, а не только изменение этой страницы. (это защита для crash recovery на тот случай, если IO записало страницу только частично, страница у нас 8кб типично, страница памяти ОС чаще 4кб, а у диска адресация может быть и 512 байт: поэтому нужно предполагать, что есть ли мы попросили записать 8кб и где-то тут всё умерло, то на дисках может быть уже записано, например, 4кб нового содержимого страницы, а других 4кб остались старые - в итоге фигня)

    Вместе с накоплением bloat получается что мы регулярно трогаем бОльшее число разных блоков, что и вызывает больше записи FPI.
    https://wiki.postgresql.org/wiki/Full_page_writes

    Из менее очевидного и не помню чтобы задокументированного (помимо исходников), часть работы автовакуума подхватит выполнение других запросов. Так называемые micro vacuum и index hint bits, когда даже select может чего-нибудь писать в WAL. Небольшие оптимизации вида "ну это не моя работа, я выполняю запрос, но блок данных вот он в руке, всю работу по проверке видимости транзакций всё равно уже сделал, подпишу для потомков примечания чтобы они не тратили время на то же самое"

    Ситуация вокруг hot_standby_feedback или max_standby_streaming_delay (max_standby_archive_delay полностью аналогично, но применяется на restore_command) в postgresql такая:
    Реплика получает поток WAL, сделанных на мастере и обнаруживает, что на мастере физически из датафайла удалены данные (обычно автовакуумом), которые ещё может хотеть прочитать запрос, запущенный на этой реплике. Пропустить это изменение и накатывать репликацию дальше нельзя. Дальнейшшие изменения запросто могут быть в этом же самом датафайле, уже полагающиеся что это изменение было применено. Остаётся не так уж много вариантов что может делать реплика:
    • или приостанавливать репликацию и подождать пока доработает запрос
    • или отменять запрос и продолжать применять репликацию
    postgresql сначала делает паузу репликации, затем по прошествии времени max_standby_streaming_delay отменяет мешающие запросы с разными вариантами terminating connection due to conflict with recovery. При этом, max_standby_streaming_delay считается от начала конфликта репликации и по таймауту снимает совсем всех кто мешает, даже если этот конкретный запрос запустился полсекунды назад.

    hot_standby_feedback же это третий вариант работы, он предписывает реплике отправлять на мастер сведения о своей самой старой транзакции. Мастер это учитывает в своей работе и не удаляет данные, которые потенциально та транзакция может ещё запросить. То есть активно мешает оперативной работе автовакуума, от чего копятся ненужные версии строк в таблицах и индексах, занимают место и замедляют обработку всех запросов, и на мастере и на всех физических репликах (т.к. запрос должен проверить, вдруг эта версия строки видна именно ему)

    Для аналитической реплики выбирается комфортный max_standby_streaming_delay. Полчаса, час, 10 часов - индивидуально по потребностям проекта. Баланс между "дать запросам поработать" и "реплика может отставать на такое время и это не авария, а полностью штатное поведение, о котором мы с вами ранее договорились"
    Написано

  • Почему увеличилась генерация WAL-сегментов?

    Melkij
    @Melkij
    hot_standby_feedback бизнес потребовать не мог. Это не бизнесовая задача. Выстрел себе в ногу в попытке починить сломавшийся или нестабильно работающий бизнес-процесс - да. Но бизнесовая проблема 100% в другом и не формулируется как "включить hot_standby_feedback".

    За счет того что автовакууму обрабатывать больше мертвых версий строк или не только?

    не только, но первопричина вернётся к этому.
    Повезёт если бонусом не ляжет вообще всё из-за замедления ответов СУБД. Некоторые проекты красиво складываются минут за 20.
    Написано

  • Postgres Docker: Странные временные файлы в папке overlay2?

    Melkij
    @Melkij
    это НЕ файлы postgresql. Не то место, не то именование.
    может быть malware работающий через взломанный postgres.
    Написано

  • Как запустить mysql после ошибки?

    Melkij
    @Melkij
    не, тут гораздо интереснее чуть выше Operating system error number 11 in a file operation.
    то есть ошибка вовсе не самого mysql, а ОС не даёт работать.
    Написано

  • Какое отставание MySQL Slave от MySQL master считать проблемным?

    Melkij
    @Melkij
    Seconds_Behind_Source но с учётом прочтения описания документации по этому полю. Там не без некоторых нюансов
    Написано

  • Как понять почему размер БД вырос на 30%?

    Melkij
    @Melkij
    3. Да были ошибки в логах о недоступности для записи таблиц.

    можно пару цитат?

    То есть основная гипотеза, vacuum full писал что-то большое, но не смог удалить либо старые либо новые датафайлы.
    База при этом не уходила ли вообще в crash recovery по какой-то причине? Там есть варианты при которых остаются осиротевшие датафайлы https://www.cybertec-postgresql.com/en/orphaned-fi...
    Написано

  • Как понять почему размер БД вырос на 30%?

    Melkij
    @Melkij
    - место занимает именно PGDATA/base/ ? PGDATA/pg_wal нормального размера?
    - "Если сделать бэкап и развернуть на другом сервере" - какой именно бекап имеется в виду?
    - ошибки в логах базы при снапшоте?
    - как именно снапшот делался? (LXC на btrfs/zfs/etc тоже можно назвать виртуалкой, а вот грабли будут свои)

    PS: vacuum full на 1,4тб базе это довольно неожиданная идея
    Написано

  • В чем может быть причина сброса значения sequence в БД?

    Melkij
    @Melkij
    если бы типичный в такой ситуации `select setval` ещё бы считался ddl командой =) не попадёт в лог, проверил только что
    Написано

  • Как обнаружить все битые таблицы?

    Melkij
    @Melkij
    Я пару файлов уже скопировал с прода и они заработали.

    И тем самым сломали MVCC логику.
    А ещё могли не заметить существование base/121622383/622439194.1 и так далее сегментов

    Восстановите базу заново но теперь корректно. Нафига вам на тестовой базе приключения
    Написано

  • Как заставить нормально работать относительно древнюю видеокарту в слоте PCIe x1?

    Melkij
    @Melkij
    проблема скорее софтовая. Когда там nvidia выбросила поддержку 8ххх из драйвера? Существовала ли в истории версия драйвера, которая поддерживает и старую и новую из ваших видеокарт?
    Два одновременно активных разных версии драйвера ожидаемо к приключениям.
    https://forums.developer.nvidia.com/t/setting-up-t...
    попробуйте вот такое для эксперимента
    https://forums.developer.nvidia.com/t/intalling-tw...
    Написано