Комментарии 22
Для желающих использовать ваш Managed Postgres я бы писал про то, что резко распухший WAL молча положит базу, когда закончится место, а саппорт будет откатывать ее пару часов с рекомендациями "просто влейте больше денег и сделайте себе мониторинг, это не наши проблемы".
Системным же решением нам видится автоматический resize диска при заканчивающемся месте (с возможностью это выключить пользователем, конечно). Про это написано в планах на будущее.
У меня были диски по 20gb для базы 10gb (объем данных) с приростом меньше 1мб в день и она умерла совсем, не read-only. Возможно cron появился после того это фейла.
Самый большой косяк, который был — мне восстановили базу и она опять умерла через час без нагрузки с той же проблемой (это было ясно заранее по графикам).
База маленькая, я быстро перевел ее на self hosted (как было всегда) и живу дальше, все ок, кроме 3ч дайнтайма апи. База — самое критическое, что есть у бизнеса, ваш подход меня совсем не устроил.
Дай, пожалуйста, номер обращения в support. И ещё вопрос, кластер состоял из одного хоста?
Кластер из двух хостов, параметры уже не помню.
156208280873784
Посмотрел ещё раз в это обращение. Возможно, база и росла со скоростью 1 МБ в день, но тогда вы её агрессивно перезаписывали, потому что в логах было такое:
[ 2019-07-02 18:45:49.881 MSK ,,,173628,00000 ]:LOG: checkpoints are occurring too frequently (49 seconds apart) [ 2019-07-02 18:45:49.881 MSK ,,,173628,00000 ]:HINT: Consider increasing the configuration parameter "max_wal_size".
Т.е. писали вы явно много. Про это вам support отвечал.
Ну и после того, как вы удалили кластер, к вам приходил менеджер, расспрашивал о произошедшем и рассказывал, почему и как такое произошло. А потому извините, но я буду считать ваш комментарий к статье набросом, а не конструктивным feedback'ом.
Мне жаль, что у меня тогда все было в огне (это реальный прод) и нужно было срочно исправить проблему, поэтому я не собрал подробный лог действий, а сейчас никакого желания пытаться сделать это еще раз.
Но я точно уверен, что с тех пор код не менялся, а база живет на похожей self hosted конфигурации без сбоев.
Может когда-то дойдут руки посмотреть как себя в таком случае ведет AWS RDS или Google Databases. И если у них так же падает бд, то к вам 0 вопросов и накидывать я перестану.
PS. База падала два раза.
После первого, сразу после восстановления и в течении часа до следующего
SELECT nspname || '.' || relname AS "relation",
pg_size_pretty(pg_relation_size(C.oid)) AS "size"
FROM pg_class C
LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
WHERE nspname NOT IN ('pg_catalog', 'information_schema')
ORDER BY pg_relation_size(C.oid) DESC
LIMIT 20;
показывал меньше 2gb. Я не представляю, что такого можно наапдейтить до падения (и до второго падения я написал в тех поддержку в tg, что сейчас все упадет еще раз и я не понимаю причину, ответили через пару часов на почту, что сам дурак стоит докинуть места)
Но я точно уверен, что с тех пор код не менялся, а база живет на похожей self hosted конфигурации без сбоев.
"У меня такая же нога и не болит" © Очевидно, что есть отличия в конфигурации. Например, вы с self-hosted базы архивируете WAL? Если нет, то вероятность закончиться месту под WAL'ом при активной записи, конечно же, сильно ниже, но тогда вы теряете возможность восстановиться из бэкапа на произвольный момент времени (а не только то время, когда был сделан бэкап).
BTW, указанный вами запрос некорректный. Функция pg_relation_size не покажет вам размеры индексов, правильнее использовать pg_total_relation_size.
Я понимаю, что конфигурации разные (и у вас она намного круче, потому что команда которая много лет админит pg). WAL не архивируется, просто master/slave с плейбуками на развертывания/свап и обычные бекапы по расписанию.
Возможно я плохо выразился. Я не хотел делать наброс или еще что. И спокойно допускаю, что мой скил плох (я же не настраиваю архивирования wal).
Но от сервиса, который обещает заботу про мою базу данных я ожидаю на порядок больше, потому что по идее он делается для тех, кто вообще ничего не понимает в администрировании. А если по какой-то причине клиент может косячить и нереально подложить соломы, то стоит выделить на это отдельную страницу в доке.
После каждого инцидента в моей инфраструктуре я добавляю метрики и алерты на это. Обычно повторов не бывает. Вы что-то сделали кроме рекомендации в личку "увеличьте диски, меньше пишите в базу"? Если ответ "мы не обязаны делать", то 0 вопросов.
Возможно я плохо выразился. Я не хотел делать наброс или еще что.
Просто Вы из довольно частного случая сделали довольно общий вывод.
Вы что-то сделали кроме рекомендации в личку "увеличьте диски, меньше пишите в базу"?
Да, у нас теперь значения параметров min_wal_size и max_wal_size выставляются в зависимости от размера диска. Ещё подкрутили параметры архивации WAL, чтобы в таких ситуациях база писала медленнее, а архивация работала быстрее. Ну и запланировали сделать auto resize диска, про это пишу уже не первый раз.
Катализаторов этого вывода послужила позиция "сами виноваты, ищите проблему у себя", без подробностей. Которую вы даже тут гнули до этого ответа. Без подробностей. И я тогда нашел проблему у себя — ваш сервис. Исправил.
Если бы мне на следующей день сказали, что min/max_wal_size поправили, запись замедлили, не повториться, то скорее всего я бы продолжил использовать сервис и перевел еще пару баз туда.
Я рекомендую знакомым ваши виртуалки и object storage, но базы данных… нет.
WebDAV на Яндекс.Диске угробили даже на платных тарифах, а альтернативы для бэкапов не предоставили. Использовать для этого Яндекс.Облако — жутко дорого.
Доверие к сервису, мягко говоря, подорвано.
Видимо, решили проспонсировать Mail.ru.
Если сравнить по калькуляторам cloud.yandex.ru/prices, mcs.mail.ru/storage, то получается:
* Яндекс.Облако 0.67 рублей за 1ГБ/месяц.
* MCS 1.6 рублей за 1 ГБ/месяц.
Работает с любыми s3 compatible объектными хранилищами.
Но я советую для бекапов пользоваться профильными утилитами, вроде restic.net, они умеют делать дедупликацию, шифрование, снапшоты и складывать в s3 сами без монтирования.
Яндекс.Диск:
Облако:
А вообще ваш комментарий не имеет никакого отношения к посту.
А насчёт Яндекс.Облака: вы «случайно» забыли надпись внизу:
«Дополнительно тарифицируется только исходящий трафик при потреблении более 10 ГБ за месяц по цене 0,96 ₽ за 1 ГБ. Входящий трафик не тарифицируется.» Но я уверен, что вы просто не заметили.
И пользоваться им хотя бы стандартным net use несколько проблематично.
Mail.ru за 750р/год для домашнего пользования и бэкапов — куда удобнее.
Какие у вас планы по кастом DNS для managed database?
Этот кейс проявляется, если я создаю managed сущности без публичного адреса и подключаюсь из on prem.
А как вы подключаетесь к базам без публичного адреса из on prem? VPN, Direct connect? Кажется, что пока единственным работающим решением будет на DNS-серверах в on prem (они же есть?) сделать форвардинг зоны mdb.yandexcloud.net в DNS-сервер Облака для вашей сети. Но это вряд ли можно назвать правильным решением.
В планах сейчас такого нет, потому что вы первый, кто спрашивает. Рекомендую это добавить в https://cloud.yandex.ru/community, чтобы другие люди эту идею лайкали и мы понимали приоритет этой задачи.
Очень печально слышать, что вы об этом не слышали. Мы это обсуждали на Yandex Scale, да и ваши аккаунт менеджеры заверяли, что FR завели. Придется усилить натиск.
Интересно, у Яндекс.Облака тоже так будут тихо отключать функции?
PS: форумы с теми же проблемами:
toster.ru/q/677787
4pda.ru/forum/index.php?showtopic=375807&st=3840
Как устроены сервисы управляемых баз данных в Яндекс.Облаке