Опубликован первый стабильный релиз новой ветки СУБД MariaDB 10.9 (10.9.2), в рамках которой развивается ответвление от MySQL, сохраняющее обратную совместимость и отличающееся интеграцией дополнительных движков хранения и расширенных возможностей. Развитие MariaDB курирует независимая организация MariaDB Foundation в соответствии с полностью открытым и прозрачным процессом разработки, не зависящим от отдельных производителей. MariaDB поставляется вместо MySQL во многих дистрибутивах Linux (RHEL, SUSE, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian) и внедрён в таких крупных проектах, как Wikipedia, Google Cloud SQL и Nimbuzz...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57669
После того, как они убили мультитредовый флашинг и запихали всю запись в один поток, InnoDB теперь упирается в одно ядро, особенно когда сжатие страниц используется. TokuDB тоже выкинули пару лет назад. И это лютый 3.14ц в сумме, когда у тебя очень большие объёмы хорошо сжимаемых данных. Плюнул, и пересел назад на MySQL 8, там нет lzma и zstd на сжатии страниц, конечно, но хоть какое-то сжатие в целом возможно.
PostgreSQL-господа смотрят на тебя с неистовым недоумением.
В pg репликация не такая хорошая как у mysql
Бггг :)
Там вакуумить регулярно уже не надо с (авто)блокировкой?
Когда будет не надо - приходите.
О, знатока сразу видно. Знаток, а зачем в Слоне автовакуум вообще? Поделитесь соображениями. Да, и что он "блокирует"?
Давай, Знаток, расскажи, что делает автовацуум в конце операции, когда обкусывает блоки.
И как себя ведёт, когда в этот момент идёт вставка.
Что там с 9 на 13 без проблем переехать можно уже??
Или как обычно с бубнами?
С бубнами любую версию. Но не так уж сложно играть то.
Можно подумать в MySQL без бубнов можно с 5 на 8 переехать
можно, вообще без проблем, если не зависишь от чего-то deprecated
>> если не зависишьBggg
> запихали всю запись в один поток, InnoDB теперь упирается в одно ядро [...] пересел назад на MySQL 8Разве они реализацию InnoDB не из ораклового MySQL тащат? Какой смысл пересаживаться на MySQL, если там те же яйца?
Не, они изнасиловали флашер.
В Оракле таки хватило мозгов не закатывать солнце назад вручную.
Использую сжатие на ZFS под MySQL 8 - там мультитредовое и прозрачно для базы и всё такое, но есть момент - ZFS крашится и уходит в себя наполовину. Наполовину это когда чтение еще работает, даже бывает какая-то запись работает, но в целом точка монтирования неживая, мускуль залипает и даже продолжает думать что репликация в UP, seconds_behind_master 0. Случается эпизодически, когда раз в месяц, когда раз в три дня.Для полутествого слейва оно как-то еще ок (докрутил через events обновление поля как некий heartbeat) балансер выкинет залипший слейв из пула (два слейва в пуле), но продакшн мастер так и живет на XFS. So sad.
BTRFS пробовал тоже, там еще хуже, деградация производительности через 3 дня, если не делать дефрагментацию постоянно.
ZFS под DB? Мсье знает толк в извращениях.
А что не так?// b.
Выше всё описано, что не так, ну да ладно.
+ CoW ну никак с логикой журналирования современных RDBMS не вяжется.
Двойная работа + слишком мелкая запись + костыльный O_DIRECT + костыльный f(data)sync.
У ZFS ещё получается аж тройное кеширование - буферный пул - системный кеш - зил-запорожец.
Что почитать на тему ZFS+DB? Знаю одного крупного клиента с ZFS+Postgres - нормально себе живут.
> Что почитать на тему ZFS+DB? Знаю одного крупного клиента с ZFS+Postgres -
> нормально себе живут.Нормально у всех разное - я тоже нормально живу в этом конкретном месте и то что падает, ну неприятно, но по набору компромиссов _в этом_ кейсе устраивает.
У тех кто живёт тоже может быть набор компромиссов, просто их не видно. Опять же у постгреса в моём понимании немного другой вариант работы WAL.
Из скажем так не совсем стандартных вариантов (сжатие на слуху и вполне себе стандартная фича) - как кэш для high latency disks типа EBS в AWS ( https://www.percona.com/blog/mysql-zfs-performance-update/ + https://www.percona.com/blog/mysql-zfs-in-the-cloud-leveragi.../ )
После слова postgres можно не продолжать. Пусть себе живут.
> Выше всё описано, что не так, ну да ладно.
> + CoW ну никак с логикой журналирования современных RDBMS не вяжется.
> Двойная работа + слишком мелкая запись + костыльный O_DIRECT + костыльный f(data)sync.
> У ZFS ещё получается аж тройное кеширование - буферный пул - системный
> кеш - зил-запорожец.Так то да, но да и хрен с ним [в этом конкретном месте] - Double write отключен. Там еще и raid0 под мускулем [силами ZFS]. Мастером стать этому серверу не грозит, а Н или даже М денег экономит на диски поменьше, чтение параллелит, репликация даже местами быстрее чем на "нормальном" слейве с XFS.
CoW и WAL ортогональны. Ни какой "двойной работы" в их сочетании нет.
> BTRFS пробовал тожесмеюсь над этим dba в голос.
рекомендации отключать журнал и write barrier на ext4 (где лежит база)
прошли мимо вас или просто не были осознаны ?
Если отключить журнал на ext4, она работает раз в 100 медленнее. Это ничего? Да и без барьеров она точно навернётся на следующей же панике (даже writeback устраивает лисец котёнку). Я больше поверю в то, что btrfs можно настроить, чем в использование ext4 таким образом (гуглу можно, у него свои собственные возможности).
> Если отключить журнал на ext4, она работает раз в 100 медленнее.1) под какой нагрузкой ?
2) почему ? я не вижу оснований.> Да и без барьеров она точно навернётся на следующей же
> паникея что-то давно не видел кернел паников. может потому что стабильное ядро с выкинутым мусором,
а может потому что железо проверенное.> Я больше поверю в то,
> что btrfs можно настроить,вера - это вопрос религиозный (а в случае btrfs похоже что тоталитарно-сектантский).
Ну с журналом _данных_ (который обычно и так того) я ещё готов согласиться.
Выключение журнала метаданных убьёт вам структуру базы в случае краша системы во время "атомарного" изменения структуры (перемещения файлов например при DDL).
Но выключение write barrier. Oh my god. Это прямой путь к потере конзистентности при ЛЮБЫХ крашах, потому что при этом fsync/fdatasync не дают никакого понимания о том, что реально на диск упало, и в каком порядке.
А зачем вообще все эти синхронные WAL-ы? Пустая трата ресурсов. Рифовая запись, бэкапы? Ну нафиг, железо же сверхстабильное и надёжное, сбоев не даёт никогда.
> отключать журнал и write barrier на ext4 (где лежит база)Да вы, я смотрю, матёрый камикадзе.
> запихали всю запись в один поток, InnoDB теперь упирается в одно ядроЯ думал запись всегда упирается в диск.
Смотря какой диск. В full-flash SAN оно точно не упирается, но объёмы здоровые, да и трафик между SAN и серверами сжатие жёстко сокращает.
>> запихали всю запись в один поток, InnoDB теперь упирается в одно ядро
> Я думал запись всегда упирается в диск.Тогда бы всякие io_uring не прикручивали к XFS. Тем у кого диски быстрые, актуально.
Запись упирается в странный вопрос -- а нужно ли это писать куда-то, кроме как в память. Чаще всего проблема с И/О в ничем не обоснованной избыточной волатильности буферных кэшей. Когда так настроено, что чекпоинт рубит чуть ли не без остановки.
1) а если я не использую сжатие?
2) если это одно ядро ну очень быстрое?
3) и что там с перконой?
1) тогда тебе это не нужно
2) таких не бывает
3) не нужно
Впрочем, в п.1 всё равно есть риск упереться если база пишется/модифицируется большими блоками.
SSD хранилище, блобы внутри базы
"Postgresql должно быть достаточно для каждого" В.И. Ленин// b.
Неправда, Ленин не говорил такого!
Всё верно. Эту цитату ошибочно приписывают Ленину, хотя написал это Маркс в одном из своих писем к Энгельсу.
"Эрих и Мария Ремарк в гостях у братьев Салтыкова и Щедрина.jpg"
Максим, что-то в последнее время модерация режет по-живому, предлагаю, это самое, как-то мягче всё-таки быть.
как вариант, давать комментировать только зареганым юзверям
Конечно, лору это помогло. А, хотя, подождите, не помогло. Ну и, в целом, не существует публики более никчёмной и бездарной, чем регистранты. Что-то полезное могут сообщить только анонимы (не такие как в ранее удалённом, надо понимать).
> Что-то полезное могут сообщить только анонимы (не такие как в ранее удалённом, надо понимать)их так мало, но они в тельняшках!
> Конечно, лору это помогло. А, хотя, подождите, не помогло.Еще как помогло. Там теперь тихо, как на кладбище...
ага и членам партии :)
Предлагаю не удалять комментарии вообще.
Тогда быстро ресурс прикроют за экстремизм и разжигание к маководам.
opennet.org?
opennet.i2p
opennetматьперематьтудасюда.onion
Люто бешено плюсую Джона Ерохина!
> ... и разжигание к маководам.и к растоманам
У меня есть вопрос. Почему на лого MariaDB нарисован Тюлень.Это тюлень по имени Мария?
Чему удивляться после дельфина по имени Май?
Тюлениха.
С их изменением политики мажорных релизов начал задумываться о том, что бы новые проекты заводить на Перконе, а не МарииКакой 10.9? У меня еще не все проекты перекатились с 10.6 на 10.7(при перекате были необъяснимые проблемы на некоторых и пришлось после тестирования отказаться и ждать когда коллеги разберутся от чего они возникают)
10.6 это LTS зачем с него перекатываться? 0_o
На некоторых проектах бывают дурные заказчики, которые могут следить за версиями используемого ПО и требовать что бы все было свежим по мажорной версииИ такое бывает
"MariaDB - это лучшая база которую я когда либо видел". (c) Альберт Эйнштейн
гамно,не нужно и название тоже гамно, ведь есть человеческий mysql
> гамно,не нужно и название тоже гамно, ведь есть человеческий mysqlЯ тебе ща шаблон порву
Названия MaxDB, MySQL и MariaDB даны одним человеком и созданы по одному принципу
Название его ПО начинается с имен его детей(сын Max и дочери My и Maria)
> Mariaпо такой логике эта мария похожа на наимерзейшего тюленя
И всё на продажу
Кусок говна, хуже Percona MySQL 8.
К сожалению да. Начиная с 10.6 что-то у них сломалось. Не в движке. В подходах.