1.2, Онаним (?), 08:49, 24/08/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
После того, как они убили мультитредовый флашинг и запихали всю запись в один поток, InnoDB теперь упирается в одно ядро, особенно когда сжатие страниц используется. TokuDB тоже выкинули пару лет назад. И это лютый 3.14ц в сумме, когда у тебя очень большие объёмы хорошо сжимаемых данных. Плюнул, и пересел назад на MySQL 8, там нет lzma и zstd на сжатии страниц, конечно, но хоть какое-то сжатие в целом возможно.
| |
|
2.7, Аноним (7), 09:12, 24/08/2022 [^] [^^] [^^^] [ответить]
| +18 +/– |
PostgreSQL-господа смотрят на тебя с неистовым недоумением.
| |
|
3.29, Онаним (?), 12:19, 24/08/2022 [^] [^^] [^^^] [ответить]
| –2 +/– |
Там вакуумить регулярно уже не надо с (авто)блокировкой?
Когда будет не надо - приходите.
| |
|
4.74, Аноним (74), 14:48, 25/08/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
О, знатока сразу видно. Знаток, а зачем в Слоне автовакуум вообще? Поделитесь соображениями. Да, и что он "блокирует"?
| |
|
5.83, Онаним (?), 17:18, 26/08/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
Давай, Знаток, расскажи, что делает автовацуум в конце операции, когда обкусывает блоки.
И как себя ведёт, когда в этот момент идёт вставка.
| |
|
|
3.48, Juha (ok), 15:51, 24/08/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
Что там с 9 на 13 без проблем переехать можно уже??
Или как обычно с бубнами?
| |
|
4.52, 1 (??), 17:24, 24/08/2022 [^] [^^] [^^^] [ответить]
| +/– |
Можно подумать в MySQL без бубнов можно с 5 на 8 переехать
| |
|
|
2.9, Аноним (9), 09:35, 24/08/2022 [^] [^^] [^^^] [ответить]
| +/– |
> запихали всю запись в один поток, InnoDB теперь упирается в одно ядро [...] пересел назад на MySQL 8
Разве они реализацию InnoDB не из ораклового MySQL тащат? Какой смысл пересаживаться на MySQL, если там те же яйца?
| |
|
3.33, Онаним (?), 12:23, 24/08/2022 [^] [^^] [^^^] [ответить]
| +/– |
В Оракле таки хватило мозгов не закатывать солнце назад вручную.
| |
|
2.21, Роман (??), 10:49, 24/08/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
Использую сжатие на ZFS под MySQL 8 - там мультитредовое и прозрачно для базы и всё такое, но есть момент - ZFS крашится и уходит в себя наполовину. Наполовину это когда чтение еще работает, даже бывает какая-то запись работает, но в целом точка монтирования неживая, мускуль залипает и даже продолжает думать что репликация в UP, seconds_behind_master 0. Случается эпизодически, когда раз в месяц, когда раз в три дня.
Для полутествого слейва оно как-то еще ок (докрутил через events обновление поля как некий heartbeat) балансер выкинет залипший слейв из пула (два слейва в пуле), но продакшн мастер так и живет на XFS. So sad.
BTRFS пробовал тоже, там еще хуже, деградация производительности через 3 дня, если не делать дефрагментацию постоянно.
| |
|
|
|
5.36, Онаним (?), 14:05, 24/08/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
Выше всё описано, что не так, ну да ладно.
+ CoW ну никак с логикой журналирования современных RDBMS не вяжется.
Двойная работа + слишком мелкая запись + костыльный O_DIRECT + костыльный f(data)sync.
У ZFS ещё получается аж тройное кеширование - буферный пул - системный кеш - зил-запорожец.
| |
|
6.42, Аноним (34), 15:12, 24/08/2022 [^] [^^] [^^^] [ответить]
| +/– |
Что почитать на тему ZFS+DB? Знаю одного крупного клиента с ZFS+Postgres - нормально себе живут.
| |
6.67, Роман (??), 03:26, 25/08/2022 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Выше всё описано, что не так, ну да ладно.
> + CoW ну никак с логикой журналирования современных RDBMS не вяжется.
> Двойная работа + слишком мелкая запись + костыльный O_DIRECT + костыльный f(data)sync.
> У ZFS ещё получается аж тройное кеширование - буферный пул - системный
> кеш - зил-запорожец.
Так то да, но да и хрен с ним [в этом конкретном месте] - Double write отключен. Там еще и raid0 под мускулем [силами ZFS]. Мастером стать этому серверу не грозит, а Н или даже М денег экономит на диски поменьше, чтение параллелит, репликация даже местами быстрее чем на "нормальном" слейве с XFS.
| |
6.75, Аноним (74), 14:57, 25/08/2022 [^] [^^] [^^^] [ответить]
| +/– |
CoW и WAL ортогональны. Ни какой "двойной работы" в их сочетании нет.
| |
|
|
|
3.69, john_erohin (?), 08:50, 25/08/2022 [^] [^^] [^^^] [ответить]
| +/– |
> BTRFS пробовал тоже
смеюсь над этим dba в голос.
рекомендации отключать журнал и write barrier на ext4 (где лежит база)
прошли мимо вас или просто не были осознаны ?
| |
|
4.71, Аноним (71), 09:06, 25/08/2022 [^] [^^] [^^^] [ответить]
| +/– |
Если отключить журнал на ext4, она работает раз в 100 медленнее. Это ничего? Да и без барьеров она точно навернётся на следующей же панике (даже writeback устраивает лисец котёнку). Я больше поверю в то, что btrfs можно настроить, чем в использование ext4 таким образом (гуглу можно, у него свои собственные возможности).
| |
|
5.73, john_erohin (?), 13:38, 25/08/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Если отключить журнал на ext4, она работает раз в 100 медленнее.
1) под какой нагрузкой ?
2) почему ? я не вижу оснований.
> Да и без барьеров она точно навернётся на следующей же
> панике
я что-то давно не видел кернел паников. может потому что стабильное ядро с выкинутым мусором,
а может потому что железо проверенное.
> Я больше поверю в то,
> что btrfs можно настроить,
вера - это вопрос религиозный (а в случае btrfs похоже что тоталитарно-сектантский).
| |
|
6.82, Онаним (?), 17:12, 26/08/2022 [^] [^^] [^^^] [ответить]
| +/– |
Ну с журналом _данных_ (который обычно и так того) я ещё готов согласиться.
Выключение журнала метаданных убьёт вам структуру базы в случае краша системы во время "атомарного" изменения структуры (перемещения файлов например при DDL).
Но выключение write barrier. Oh my god. Это прямой путь к потере конзистентности при ЛЮБЫХ крашах, потому что при этом fsync/fdatasync не дают никакого понимания о том, что реально на диск упало, и в каком порядке.
| |
|
|
4.76, Аноним (74), 14:59, 25/08/2022 [^] [^^] [^^^] [ответить]
| +/– |
А зачем вообще все эти синхронные WAL-ы? Пустая трата ресурсов. Рифовая запись, бэкапы? Ну нафиг, железо же сверхстабильное и надёжное, сбоев не даёт никогда.
| |
4.81, Онаним (?), 17:10, 26/08/2022 [^] [^^] [^^^] [ответить]
| +/– |
> отключать журнал и write barrier на ext4 (где лежит база)
Да вы, я смотрю, матёрый камикадзе.
| |
|
|
2.26, pashev.ru (?), 11:59, 24/08/2022 [^] [^^] [^^^] [ответить]
| +/– |
> запихали всю запись в один поток, InnoDB теперь упирается в одно ядро
Я думал запись всегда упирается в диск.
| |
|
3.32, Онаним (?), 12:21, 24/08/2022 [^] [^^] [^^^] [ответить]
| +/– |
Смотря какой диск. В full-flash SAN оно точно не упирается, но объёмы здоровые, да и трафик между SAN и серверами сжатие жёстко сокращает.
| |
3.47, Роман (??), 15:42, 24/08/2022 [^] [^^] [^^^] [ответить]
| +/– |
>> запихали всю запись в один поток, InnoDB теперь упирается в одно ядро
> Я думал запись всегда упирается в диск.
Тогда бы всякие io_uring не прикручивали к XFS. Тем у кого диски быстрые, актуально.
| |
3.77, Аноним (74), 15:04, 25/08/2022 [^] [^^] [^^^] [ответить]
| +/– |
Запись упирается в странный вопрос -- а нужно ли это писать куда-то, кроме как в память. Чаще всего проблема с И/О в ничем не обоснованной избыточной волатильности буферных кэшей. Когда так настроено, что чекпоинт рубит чуть ли не без остановки.
| |
|
2.58, penetrator (?), 18:44, 24/08/2022 [^] [^^] [^^^] [ответить]
| +/– |
1) а если я не использую сжатие?
2) если это одно ядро ну очень быстрое?
3) и что там с перконой?
| |
|
3.63, Онаним (?), 22:39, 24/08/2022 [^] [^^] [^^^] [ответить]
| +/– |
Впрочем, в п.1 всё равно есть риск упереться если база пишется/модифицируется большими блоками.
| |
|
|
1.14, Аноним (14), 10:12, 24/08/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Максим, что-то в последнее время модерация режет по-живому, предлагаю, это самое, как-то мягче всё-таки быть.
| |
|
|
3.17, Аноним (71), 10:18, 24/08/2022 [^] [^^] [^^^] [ответить]
| +3 +/– |
Конечно, лору это помогло. А, хотя, подождите, не помогло. Ну и, в целом, не существует публики более никчёмной и бездарной, чем регистранты. Что-то полезное могут сообщить только анонимы (не такие как в ранее удалённом, надо понимать).
| |
|
4.24, Аноним (14), 10:52, 24/08/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Что-то полезное могут сообщить только анонимы (не такие как в ранее удалённом, надо понимать)
их так мало, но они в тельняшках!
| |
4.85, TydymBydym (?), 01:38, 07/10/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Конечно, лору это помогло. А, хотя, подождите, не помогло.
Еще как помогло. Там теперь тихо, как на кладбище...
| |
|
|
|
3.39, 1 (??), 14:14, 24/08/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
Тогда быстро ресурс прикроют за экстремизм и разжигание к маководам.
| |
|
|
1.15, Простоник (ok), 10:13, 24/08/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
У меня есть вопрос. Почему на лого MariaDB нарисован Тюлень.Это тюлень по имени Мария?
| |
1.19, hefenud (ok), 10:47, 24/08/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
С их изменением политики мажорных релизов начал задумываться о том, что бы новые проекты заводить на Перконе, а не Марии
Какой 10.9? У меня еще не все проекты перекатились с 10.6 на 10.7(при перекате были необъяснимые проблемы на некоторых и пришлось после тестирования отказаться и ждать когда коллеги разберутся от чего они возникают)
| |
|
|
3.43, hefenud (ok), 15:14, 24/08/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
На некоторых проектах бывают дурные заказчики, которые могут следить за версиями используемого ПО и требовать что бы все было свежим по мажорной версии
И такое бывает
| |
|
|
1.35, Аноним (35), 13:48, 24/08/2022 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
"MariaDB - это лучшая база которую я когда либо видел". (c) Альберт Эйнштейн
| |
|
2.44, hefenud (ok), 15:19, 24/08/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
> гамно,не нужно и название тоже гамно, ведь есть человеческий mysql
Я тебе ща шаблон порву
Названия MaxDB, MySQL и MariaDB даны одним человеком и созданы по одному принципу
Название его ПО начинается с имен его детей(сын Max и дочери My и Maria)
| |
|
3.51, Аноним (51), 16:24, 24/08/2022 [^] [^^] [^^^] [ответить]
| +3 +/– |
> Maria
по такой логике эта мария похожа на наимерзейшего тюленя
| |
|
|
|
2.64, Онаним (?), 22:40, 24/08/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
К сожалению да. Начиная с 10.6 что-то у них сломалось. Не в движке. В подходах.
| |
|
|