И о конкурентах

[nataraj]

Вчера в беседе с alexkuklin с удивлением для себя узнал, что mysql при апгрейде с версии на версию не требует апдейта базы. Новая версия просто кушает бинарное хранилище от старой.

Казалось бы, это ровно то чего хочет пользователь. Просто обновляешься и оно просто работает. Всеобщее счастье и благорастворение воздухов. Но...

Какой ценой это достигается? Достигается это ценой того, что база в себе тащит код для обратной совместимости.
Во-первых это не паханное поле граблей. Это комбинация N версий хранилища на M версий движка. В каком месте что там стрельнет -- даже Рогозину не снилось.
Во-вторых этот весь код N*M надо поддерживать от релиза к релизу, это стоит ресурсов достойных другого примирения.
В-третьих, сюрприз(!) если не обновлять бинарное хранилище, то не начнут работать оптимизации новых версий, связанные с хранением. То есть ты базу обновляешь, а она быстрее работать не начинает!
В-четвертых, если таки захотелось пользоваться новым движком, то, по словам alexkuklin базу данных надо пересоздавать. Как при царском режиме. То есть не натравить на нее программу апгрейда, а именно dump/restore.

Я конечно полагаю что разработчики mysql знают что они делают, тем или иным способом они каждую из этих проблем решают,или минимизируют ущерб. И наверное для базы данных маленьких личных хостингов это решение вполне уместно. Но все что за пределами -- это не уместно совершенно.

Так что покупайте наших слонов! На дельфинах далеко не уедешь!! ;-)

Comments

[alexkuklin.livejournal.com]

Коля, ты бы не перепевал Рабиновича, который перепел Битлз.
В одном инстансе mysql может быть более одной базы, и эти базы могут быть в разных storage engine.
И даже таблицы могут быть в разных storage engine.

[ask-ripe.livejournal.com]

Блин, я всегда думал, что pg не для работы, а для игр. Но чтобы настолько? Мало того, что его приходится собирать руками (о более чем одной версии на хосте авторы не догадываются, размер файлов в wal только для игр, а не для жизни.)
Но ок, это можно списать на идиотов - авторов дистрибутива, не имеющих отношения к продуктивам...

Так теперь оказывается, что его авторы гордятся его не применимостью в реальной жизни? Те обновив по я обязан обновить и базу? И это кто-то рекомендует для прода? Хм. Только в Луганск, их [полицию] не жалко.

[shaplov.livejournal.com]

Гор, ты конечно товарищ авторитетный, но если я правильно понимаю жизнь с большими инсталляциями, переход с версии на версию -- это все равно дни а то и недели подготовки и часы даунтайма. Запуск отдельной функции которая подправит бинарный файл под новую версию -- далеко не самое затратное из всего того что случается при процессе миграции...
Или я себе не правильно представляю жизнь?

[alexkuklin.livejournal.com]

часы даунтайма?
риалли?
без волчьего билета "вон из профессии"?

[shaplov.livejournal.com]

Слушай, когда сбербанк планово прекращает обслуживание карточек с полуночи до пяти утра, как думаешь, чем они в это время занимаются?

[beldmit.livejournal.com]

Не апгрейдом базы данных.

За Сбербанк не скажу, а коллеги из-за стенки свою СУБД апгрейдят минут за 20-30.

[ask-ripe.livejournal.com]

я тебе честно скажу (за сбер) - вот чтобы планово остановить процессинг на 5 часов - я такого даже не помню (с 2006 по 2012 год)

HCFB - да, 15-30 минут даунтайма раз в квартал планово. но БД при это не трогалась. технологические обновления - да, ставились.

[ask-ripe.livejournal.com]

Все верно. Но ты предполагаешь "умеренно оптимистичный сценарий". Даже не слегка пессимистичный.

В тоже время я точно знаю - сейчас все хорошо, может быть куда как хуже.

[ask-ripe.livejournal.com]

Коля, а сколько времени ты будешь править 20-30 тб бинарный файл? Можешь ли ты править его частями? И сколько времени ты будешь его восставливать? И можешь ли ты это сделать частями?

[ask-ripe.livejournal.com]

BTW - может пересечемся где-нибудь на чай? Я тебя расскажу про постгрес, ты мне - что не все так плохо...

[shaplov.livejournal.com]

Давай попробуем на следующей неделе. После pgconf.ru

А то у меня то ли жесткая обратная акклиматизация после Индии, то ли заболеваю я. Короче не круто мне. Так что не срочные дела лучше чуть на потом :-)

[beldmit.livejournal.com]

Возьмите третьим. Послушаю опытных людей.

[astarsan.livejournal.com]

Надо заметить что пока не возникало вопроса как pg_upgrade провести на бинарно несовместимых форматах файлов с данными.
А когда возникает получаются вот такие интересные фишки как:
"Reduce GIN index size (Alexander Korotkov, Heikki Linnakangas)
Indexes upgraded via pg_upgrade will work fine but will still be in the old, larger GIN format. Use REINDEX to recreate old GIN indexes in the new format."
Что по сути не смертельно и если думать головой а не читать что в release notes написано (я про Use REINDEX) - то перестройка индексов делается без downtime.

А еще есть задачка называемая "как включить checksum для даннызх на большой базе которой лет и лет" и которая решается только через Slony или pglogical на другой сервер.

Так что не все так просто.

PS: мой личный рекорд обновления с 9.3 на 9.4 от момента стопа базы до начала обслуживания запросов уже новой версией - 3 минуты (даже приложение не отключали просто запаузили на pgbouncer). Полчаса - это или неправильно проведена подготовка или сервер очень тормозной по IO или что то не учли и не прогнали в тестовой среде процедуру (в 10 минут уложится почти всегда можно).