Мне обычно хватает rss подписки на ряд источников, просмотреть глазами заголовки к 20-30 статьям/новостям, которые там появляются - на это надо несколько секунд, затем уже погружаешься в интересующую тебя тему при необходимости.
Спорная на мой взгляд мысль о том, что профессия ДБА уходит. Я помню ещё где-то в 2014 году нас уже начинали пугать тем, что вот-вот Oracle создаст самонастраивающуюся БД, в которой ДБА совсем будет не нужен. Но с тех пор прошёл год, прошло два, а Oracle становился всё сложнее и сложнее. Когда я с ним работал в последний раз какие-то намёки на это решение в облаках уже были, но что-то мне подсказывает, что там до сих пор идут усложнения. В PG, те же процессы - с каждой версией, появляется больше крутилок, которые позволяют настроить те или иные процессы. Программисты не перестают писать запросы, которые иногда очень плохо работает на боевых базах. То есть нужны люди, которые следят за базами, которые знают почему тут делать так хорошо, а так плохо. ИИ? Правда, несколько раз спрашивал у того же DeepSeek какую-то нужную мне информацию - процентов 70% ответов были совсем мимо. Понятно, что какие-то простые вещи ты уже не спрашиваешь в силу насмотренности, по простым вещам - он может ответить. Но чуть сложнее копни и приехали. У знакомого фирма, они вроде бы неплохие devops'ы. Рассказывал - что очень трудно найти людей, которые понимают, что именно они делают (говорил, что спрашивал базовые вещи, которые админы должны знать). Ну то есть на мой взгляд, потребность в профессионалах, будь они DBA, DevOps, да хоть кто на самом деле, будет всегда.
Специфика нашей работы в том, что мы поддерживаем чужие базы, поэтому, то, что в PG завезли uuidv7, это, конечно хорошо и спасибо Андрею за этот труд. Но мы будем осуществлять поддержку хоть с ними хоть без них. Чисто с точки зрения ДБА, на мой взгляд самым интересным тут является skip scan - это то, с чем мы будем сталкиваться каждый день, перенос статистики при апгрейде позволит значительно уменьшить время даунтайма при апгрейде. get_stat_get_backend_wal - интересно, нужно будет посмотреть, не то, чтобы прям супер нужная вещь, но интересно. autovacuum_vacuum_max_threshold - тоже полезная штука в ряде случаев. aio - надо будет позже смотреть, как себя будет вести, но тоже безусловно полезная штука Неожиданно было про LO, почему-то у меня было ощущение, что их когда-то реализовали и с тех пор таскают за собой для обратной совместимости, ан нет - развивают потихоньку :) Было бы интересно получить индексы по виртуальным столбцам - к примеру uuidv7 внедрили, из него можно created_at выдирать, но если по этому столбцу идёт поиск, то получается, что информация будет дублироваться по сути, но, видимо, это задел для будущих версий. Ну то есть да - очень интересная версия.
Добрый день! Рад, что статья приносит пользу спустя столько лет с момента её написания :) Мне на самом деле сложно ответить на этот вопрос. В пользу моего подхода я могу сказать то, что у меня есть один крон на одной машине, и этот крон запускает создание довольно большого количества бэкапов, разнесённых по времени, то есть я размазываю нагрузку на сервер бэкапов по времени. Если серверов с базами много, и вы просто подмонтируете раздел по nfs, то у каждого сервера будет свой крон и хотя бы с точки зрения того, что надо ходить по серверам и смотреть где какое расписание записано - это уже будет не особо удобно.
У меня ушёл не один месяц на то, чтобы разобраться со всеми этими утилитами. И то я не могу сказать, что разобрался полностью :) Меня всегда удивляло мнение, что патрони стал стандартом. Никогда не понимал - то-ли люди его только поверхностно изучали, то-ли ставили посредством каких-то ансибл скриптов, не особо разбираясь что к чему. И в течение того времени, что я разбирался, я раза 3 приставал к Александру с вопросами (не мог найти ответ в документации) :)
pg_waldump это инструмент по очеловечиванию записей из журналов wal - он показывает что именно там записано. Про то, что записи с commit могут находиться ниже - да, конечно это так - в одной транзакции может быть несколько действий и все они должны быть отражены в wal.
Да, если вы делаете бэкап с реплики, то он будет ждать когда произойдёт переключение журнала. Но на самом деле это не такая уж и большая проблема - вы можете установить archive_timeout в какое-то приемлемое для вас значение. Например, поставьте в archive_timeout значение в 3 минуты. При отсутствии активности вы максимум будете ждать эти самые 3 минуты. Понятно, что если никакой активности нет, то в любом случае за день у вас будет сгенерировано 7,68 Гб пустых wal-файлов, но не думаю, что это большая цена за то, чтобы снимать бэкапы с реплики. На всякий случай подчеркну, что снимать бэкапы с реплики можно только в том случае, если есть мониторинг отставания этой самой реплики. Чтобы не получилось так, что реплика отстала, а вы продолжаете снимать с неё бэкапы.
Вернулся с отпуска, только увидел комментарий :) Смотрите - в тексте есть объяснение - Поскольку в рассматриваемой ситуации мы переходим от автономных резервных копий (сделанных в режиме stream) к архивным (в режиме archive), то может возникнуть ситуация, в которой мы сделали копию, когда архивный режим ещё не был включён, после чего часть сегментов WAL уже оказалась удалена. Это означает, что первая резервная копия после перехода на архивный режим не может быть сделана в режиме PAGE, т.к. отрезок WAL в архиве между прошлой и текущей копией может не является целостным.
То есть в статье я делаю переход между одним типом бэкапов и другим. После того как такая копия будет сделана, уже можно будет переходить только на ARCHIVE режим, без опасения того, что какие-то, нужные для восстановления wal-файлы будут утеряны.
Думаю, да, это из-за более активного использования правой клавиатуры, всё-так левой руке гораздо меньше внимания уделяется, хотя и там мы гаммы на скорость играли. Про "Полёт шмеля" - да - это первое, что вспоминается, когда говоришь про скорость игры :)
А что значит "независимая"? Понятно, что если ты правша, то большую часть работы выполняешь правой рукой и она более развита, скажем, я засекал, в произведении "Ехал козак за Дунай" был довольно быстрый отрезок, я его на время играл - потом делил - оказалось, что 12 нажатий в секунду, для левой руки таких темпов в тех произведения, что я играл не было, даже на выборном баяне.
Когда учился в институте, инферно был моим любимым замком за то, что два последних юнита были летающими и осады замков проходили очень просто. Да и pvp нормально было - и некромантеров выносил... Понятно, что уровень игры просто никакой был, но кого это волновало :)
Мне обычно хватает rss подписки на ряд источников, просмотреть глазами заголовки к 20-30 статьям/новостям, которые там появляются - на это надо несколько секунд, затем уже погружаешься в интересующую тебя тему при необходимости.
Спорная на мой взгляд мысль о том, что профессия ДБА уходит. Я помню ещё где-то в 2014 году нас уже начинали пугать тем, что вот-вот Oracle создаст самонастраивающуюся БД, в которой ДБА совсем будет не нужен. Но с тех пор прошёл год, прошло два, а Oracle становился всё сложнее и сложнее. Когда я с ним работал в последний раз какие-то намёки на это решение в облаках уже были, но что-то мне подсказывает, что там до сих пор идут усложнения.
В PG, те же процессы - с каждой версией, появляется больше крутилок, которые позволяют настроить те или иные процессы. Программисты не перестают писать запросы, которые иногда очень плохо работает на боевых базах. То есть нужны люди, которые следят за базами, которые знают почему тут делать так хорошо, а так плохо.
ИИ? Правда, несколько раз спрашивал у того же DeepSeek какую-то нужную мне информацию - процентов 70% ответов были совсем мимо. Понятно, что какие-то простые вещи ты уже не спрашиваешь в силу насмотренности, по простым вещам - он может ответить. Но чуть сложнее копни и приехали.
У знакомого фирма, они вроде бы неплохие devops'ы. Рассказывал - что очень трудно найти людей, которые понимают, что именно они делают (говорил, что спрашивал базовые вещи, которые админы должны знать). Ну то есть на мой взгляд, потребность в профессионалах, будь они DBA, DevOps, да хоть кто на самом деле, будет всегда.
Специфика нашей работы в том, что мы поддерживаем чужие базы, поэтому, то, что в PG завезли uuidv7, это, конечно хорошо и спасибо Андрею за этот труд. Но мы будем осуществлять поддержку хоть с ними хоть без них. Чисто с точки зрения ДБА, на мой взгляд самым интересным тут является skip scan - это то, с чем мы будем сталкиваться каждый день, перенос статистики при апгрейде позволит значительно уменьшить время даунтайма при апгрейде. get_stat_get_backend_wal - интересно, нужно будет посмотреть, не то, чтобы прям супер нужная вещь, но интересно. autovacuum_vacuum_max_threshold - тоже полезная штука в ряде случаев. aio - надо будет позже смотреть, как себя будет вести, но тоже безусловно полезная штука Неожиданно было про LO, почему-то у меня было ощущение, что их когда-то реализовали и с тех пор таскают за собой для обратной совместимости, ан нет - развивают потихоньку :) Было бы интересно получить индексы по виртуальным столбцам - к примеру uuidv7 внедрили, из него можно created_at выдирать, но если по этому столбцу идёт поиск, то получается, что информация будет дублироваться по сути, но, видимо, это задел для будущих версий.
Ну то есть да - очень интересная версия.
Очень интересной обещает быть эта версия.
Когда-то давно уже наталкивался на утилиту https://github.com/lzlabs/pg_dumpbinary , мне кажется, она решает ту же самую проблему.
Изменение версии glibc может поломать некоторые индексы.
Добрый день! Рад, что статья приносит пользу спустя столько лет с момента её написания :) Мне на самом деле сложно ответить на этот вопрос. В пользу моего подхода я могу сказать то, что у меня есть один крон на одной машине, и этот крон запускает создание довольно большого количества бэкапов, разнесённых по времени, то есть я размазываю нагрузку на сервер бэкапов по времени. Если серверов с базами много, и вы просто подмонтируете раздел по nfs, то у каждого сервера будет свой крон и хотя бы с точки зрения того, что надо ходить по серверам и смотреть где какое расписание записано - это уже будет не особо удобно.
kitty+SuperPutty, полёт нормальный. За возможность заморозки экрана нажатием ctrl+F9 можно памятник ставить :)
У меня ушёл не один месяц на то, чтобы разобраться со всеми этими утилитами. И то я не могу сказать, что разобрался полностью :) Меня всегда удивляло мнение, что патрони стал стандартом. Никогда не понимал - то-ли люди его только поверхностно изучали, то-ли ставили посредством каких-то ансибл скриптов, не особо разбираясь что к чему. И в течение того времени, что я разбирался, я раза 3 приставал к Александру с вопросами (не мог найти ответ в документации) :)
Новый баунсер умеет prepared statemens
Помню, в каком-то очень древнем выпуске "Науки и жизни" была статья как самостоятельно сделать ботинки для горных лыж, там тоже интересно было :)
Это, конечно, всё хорошо, но на самом сайте перконы есть вот такое замечание:
https://docs.percona.com/percona-monitoring-and-management/setting-up/client/postgresql.html
While we recommend use of the newer pg_stat_monitor extension, be aware it is currently in beta phase and unsupported.
pg_waldump это инструмент по очеловечиванию записей из журналов wal - он показывает что именно там записано. Про то, что записи с commit могут находиться ниже - да, конечно это так - в одной транзакции может быть несколько действий и все они должны быть отражены в wal.
Спасибо за комментарий, Егор! Удаление было из pg_depend.
Да, если вы делаете бэкап с реплики, то он будет ждать когда произойдёт переключение журнала. Но на самом деле это не такая уж и большая проблема - вы можете установить archive_timeout в какое-то приемлемое для вас значение. Например, поставьте в archive_timeout значение в 3 минуты. При отсутствии активности вы максимум будете ждать эти самые 3 минуты. Понятно, что если никакой активности нет, то в любом случае за день у вас будет сгенерировано 7,68 Гб пустых wal-файлов, но не думаю, что это большая цена за то, чтобы снимать бэкапы с реплики. На всякий случай подчеркну, что снимать бэкапы с реплики можно только в том случае, если есть мониторинг отставания этой самой реплики. Чтобы не получилось так, что реплика отстала, а вы продолжаете снимать с неё бэкапы.
Вернулся с отпуска, только увидел комментарий :) Смотрите - в тексте есть объяснение -
Поскольку в рассматриваемой ситуации мы переходим от автономных резервных копий (сделанных в режиме stream) к архивным (в режиме archive), то может возникнуть ситуация, в которой мы сделали копию, когда архивный режим ещё не был включён, после чего часть сегментов WAL уже оказалась удалена. Это означает, что первая резервная копия после перехода на архивный режим не может быть сделана в режиме PAGE, т.к. отрезок WAL в архиве между прошлой и текущей копией может не является целостным.То есть в статье я делаю переход между одним типом бэкапов и другим. После того как такая копия будет сделана, уже можно будет переходить только на ARCHIVE режим, без опасения того, что какие-то, нужные для восстановления wal-файлы будут утеряны.
Думаю, да, это из-за более активного использования правой клавиатуры, всё-так левой руке гораздо меньше внимания уделяется, хотя и там мы гаммы на скорость играли. Про "Полёт шмеля" - да - это первое, что вспоминается, когда говоришь про скорость игры :)
А что значит "независимая"? Понятно, что если ты правша, то большую часть работы выполняешь правой рукой и она более развита, скажем, я засекал, в произведении "Ехал козак за Дунай" был довольно быстрый отрезок, я его на время играл - потом делил - оказалось, что 12 нажатий в секунду, для левой руки таких темпов в тех произведения, что я играл не было, даже на выборном баяне.
В детстве закончил музыкальную школу по классу баяна, сижу, читаю и улыбаюсь.
Когда учился в институте, инферно был моим любимым замком за то, что два последних юнита были летающими и осады замков проходили очень просто. Да и pvp нормально было - и некромантеров выносил... Понятно, что уровень игры просто никакой был, но кого это волновало :)