У нас Mariadb 10.10, Galera, база InnoDB, Перконой пользуемся постоянно для миграций, показала себя отлично.
Наша проблема не в размере базы (~570G на сжатом ZFS весит ~170G, а в фрагментации индексов и иногда в переполнении поля автоинкремента в некоторых таблицах (в основном в логах действий пользователей). Для решения этих проблем тоже планируем использовать pt-online-schema-change, но пока руки не дошли, т.к сначала запланирован переход на Марию 11.4.
Если у ТС остро стоит проблема размера БД на диске, рекомендую попробовать ZFS. Не знаю, насколько эффективно сжатие таблиц TokuDB, да и хранение их на ZFS в целом, не имел дела с этим движком, но таблицы InnoDB с определенным тюнингом и ФС и движка, полет нормальный, эффективность сжатия lz4 на средних по агрессивности настройках отлично справляется с функцией экономии места, плата процессором не такая уж и высокая, с учётом того, что алгоритм на аппаратном уровне поддерживается нашими процессорами. Чтение с диска за счёт сжатия заметно ускоряется, замедление записи в пределах погрешности измерений. А снапшоты - вообще вещ!
Скорее, дело в том, что деньги на эти проекты привыкли добывать именно на деревьях субсидий грантов и дотаций. А как речь заходит за поиск инвестора, оказывается что король-то голый.
IaC это конечно хорошо и замечательно, но если происходит нештатная ситуация, которая не обрабатывается на уровне автоматизации (по причине невозможности, или просто кто-то косякнул, или не подумали что такое может быть), то приходится лезть ручками, чтобы как минимум понять, что произошло и с чем это едят, возможно, если изменения затрагивают небольшое количество машин - аварийно починить. А потом уже вносить правки в автоматику развертывания Из последних у меня было:
Отсохла сетевуха в датацентре (ну, тут VRRP справился, но сообщение о даунтайме 5 секунд пришло)
Другой сервис изменил настройки интеграции и ничего не сказал
Прогеры вкатили какую-то слонячью миграцию в базу и Galera на несколько секунд встала на паузу, чтобы разлиться/догнаться (опять даунтайм около 5 секунд)
Было бы неплохо рассмотреть предложенные кейсы в формате сравнения с решением аналогичной задачи посредствам обычного файлового хранилища, чтобы были более очевидны плюсы и минусы использования той или иной технологии.
Ну, если упрощенно, то по большей части соответствует действительности. Разнятся только инструменты: У кого-то чаще RDP, у кого-то SSH через кучу джампов, вэб-консоли от разных софтин, типа проксмокса и прочие графаны с заббиксами. И да, ssh-клиенты на всем, чем можно: на смартфоне, планшете и т.д. Разные звуки на уведомления разного уровня критичности решает проблему подрыва по пустякам, зачем резко подрываться, если отстала одна из нод кластера БД? Отстегнется, догонится и пристегнется обратно, причины можно и утром разобрать :) А вот если website is down - тут уже пофиг что 3 часа ночи, надо вставать и делать.
Украсть админа с ноутом, конечно, идея интересная, но чО уж сразу не директора своровать, он имеет доступ кще и к деньгам :)
Наврал немного. Нет у нас аппаратной поддержки lz4.
У нас Mariadb 10.10, Galera, база InnoDB, Перконой пользуемся постоянно для миграций, показала себя отлично.
Наша проблема не в размере базы (~570G на сжатом ZFS весит ~170G, а в фрагментации индексов и иногда в переполнении поля автоинкремента в некоторых таблицах (в основном в логах действий пользователей). Для решения этих проблем тоже планируем использовать pt-online-schema-change, но пока руки не дошли, т.к сначала запланирован переход на Марию 11.4.
Если у ТС остро стоит проблема размера БД на диске, рекомендую попробовать ZFS. Не знаю, насколько эффективно сжатие таблиц TokuDB, да и хранение их на ZFS в целом, не имел дела с этим движком, но таблицы InnoDB с определенным тюнингом и ФС и движка, полет нормальный, эффективность сжатия lz4 на средних по агрессивности настройках отлично справляется с функцией экономии места, плата процессором не такая уж и высокая, с учётом того, что алгоритм на аппаратном уровне поддерживается нашими процессорами. Чтение с диска за счёт сжатия заметно ускоряется, замедление записи в пределах погрешности измерений. А снапшоты - вообще вещ!
Скорее, дело в том, что деньги на эти проекты привыкли добывать именно на деревьях субсидий грантов и дотаций. А как речь заходит за поиск инвестора, оказывается что король-то голый.
Просто надо использовать браузер "Амиго"
IaC это конечно хорошо и замечательно, но если происходит нештатная ситуация, которая не обрабатывается на уровне автоматизации (по причине невозможности, или просто кто-то косякнул, или не подумали что такое может быть), то приходится лезть ручками, чтобы как минимум понять, что произошло и с чем это едят, возможно, если изменения затрагивают небольшое количество машин - аварийно починить. А потом уже вносить правки в автоматику развертывания Из последних у меня было:
Отсохла сетевуха в датацентре (ну, тут VRRP справился, но сообщение о даунтайме 5 секунд пришло)
Другой сервис изменил настройки интеграции и ничего не сказал
Прогеры вкатили какую-то слонячью миграцию в базу и Galera на несколько секунд встала на паузу, чтобы разлиться/догнаться (опять даунтайм около 5 секунд)
Было бы неплохо рассмотреть предложенные кейсы в формате сравнения с решением аналогичной задачи посредствам обычного файлового хранилища, чтобы были более очевидны плюсы и минусы использования той или иной технологии.
Ну, если упрощенно, то по большей части соответствует действительности. Разнятся только инструменты: У кого-то чаще RDP, у кого-то SSH через кучу джампов, вэб-консоли от разных софтин, типа проксмокса и прочие графаны с заббиксами. И да, ssh-клиенты на всем, чем можно: на смартфоне, планшете и т.д. Разные звуки на уведомления разного уровня критичности решает проблему подрыва по пустякам, зачем резко подрываться, если отстала одна из нод кластера БД? Отстегнется, догонится и пристегнется обратно, причины можно и утром разобрать :) А вот если website is down - тут уже пофиг что 3 часа ночи, надо вставать и делать.
Украсть админа с ноутом, конечно, идея интересная, но чО уж сразу не директора своровать, он имеет доступ кще и к деньгам :)
cat /dev/zero > /dev/null &