Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Стабильный выпуск СУБД MariaDB 10.9"	+/–
Сообщение от opennews (??), 24-Авг-22, 08:46
Опубликован первый стабильный релиз новой ветки СУБД 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.me/opennews/art.shtml?num=57669
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

2. Сообщение от Онаним (?), 24-Авг-22, 08:49	+2 +/–
После того, как они убили мультитредовый флашинг и запихали всю запись в один поток, InnoDB теперь упирается в одно ядро, особенно когда сжатие страниц используется. TokuDB тоже выкинули пару лет назад. И это лютый 3.14ц в сумме, когда у тебя очень большие объёмы хорошо сжимаемых данных.  Плюнул, и пересел назад на MySQL 8, там нет lzma и zstd на сжатии страниц, конечно, но хоть какое-то сжатие в целом возможно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #9, #21, #26, #58

7. Сообщение от Аноним (7), 24-Авг-22, 09:12	+18 +/–
PostgreSQL-господа смотрят на тебя с неистовым недоумением.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #10, #29, #48

8. Сообщение от Аноним (34), 24-Авг-22, 09:17	+/–
"Postgresql должно быть достаточно для каждого" В.И. Ленин // b.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25

9. Сообщение от Аноним (9), 24-Авг-22, 09:35	+/–
> запихали всю запись в один поток, InnoDB теперь упирается в одно ядро [...] пересел назад на MySQL 8 Разве они реализацию InnoDB не из ораклового MySQL тащат? Какой смысл пересаживаться на MySQL, если там те же яйца?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #30, #33

10. Сообщение от Alex (??), 24-Авг-22, 09:42	–4 +/–
В pg репликация не такая хорошая как у mysql
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #27

14. Сообщение от Аноним (14), 24-Авг-22, 10:12	+1 +/–
Максим, что-то в последнее время модерация режет по-живому, предлагаю, это самое, как-то мягче всё-таки быть.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16, #22

15. Сообщение от Простоник (ok), 24-Авг-22, 10:13	+3 +/–
У меня есть вопрос. Почему на лого MariaDB нарисован Тюлень.Это тюлень по имени Мария?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20, #23

16. Сообщение от Аноним (14), 24-Авг-22, 10:13	–2 +/–
как вариант, давать комментировать только зареганым юзверям
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #17, #18

17. Сообщение от Аноним (71), 24-Авг-22, 10:18	+3 +/–
Конечно, лору это помогло. А, хотя, подождите, не помогло. Ну и, в целом, не существует публики более никчёмной и бездарной, чем регистранты. Что-то полезное могут сообщить только анонимы (не такие как в ранее удалённом, надо понимать).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #24, #85

18. Сообщение от Sw00p aka Jerom (?), 24-Авг-22, 10:27	+1 +/–
ага и членам партии :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

19. Сообщение от hefenud (ok), 24-Авг-22, 10:47	+1 +/–
С их изменением политики мажорных релизов начал задумываться о том, что бы новые проекты заводить на Перконе, а не Марии Какой 10.9? У меня еще не все проекты перекатились с 10.6 на 10.7(при перекате были необъяснимые проблемы на некоторых и пришлось после тестирования отказаться и ждать когда коллеги разберутся от чего они возникают)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #37

20. Сообщение от www2 (??), 24-Авг-22, 10:47	+/–
Чему удивляться после дельфина по имени Май?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

21. Сообщение от Роман (??), 24-Авг-22, 10:49	–1 +/–
Использую сжатие на ZFS под MySQL 8 - там мультитредовое и прозрачно для базы и всё такое, но есть момент - ZFS крашится и уходит в себя наполовину. Наполовину это когда чтение еще работает, даже бывает какая-то запись работает, но в целом точка монтирования неживая, мускуль залипает и даже продолжает думать что репликация в UP, seconds_behind_master 0. Случается эпизодически, когда раз в месяц, когда раз в три дня. Для полутествого слейва оно как-то еще ок (докрутил через events обновление поля как некий heartbeat) балансер выкинет залипший слейв из пула (два слейва в пуле), но продакшн мастер так и живет на XFS. So sad. BTRFS пробовал тоже, там еще хуже, деградация производительности через 3 дня, если не делать дефрагментацию постоянно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #31, #69

22. Сообщение от Аноним (22), 24-Авг-22, 10:50	–1 +/–
Предлагаю не удалять комментарии вообще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #39

23. Сообщение от Аноним (22), 24-Авг-22, 10:50	+/–
Тюлениха.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

24. Сообщение от Аноним (14), 24-Авг-22, 10:52	+/–
> Что-то полезное могут сообщить только анонимы (не такие как в ранее удалённом, надо понимать) их так мало, но они в тельняшках!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

25. Сообщение от Аноним (-), 24-Авг-22, 11:02	+4 +/–
Неправда, Ленин не говорил такого!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #38

26. Сообщение от pashev.ru (?), 24-Авг-22, 11:59	+/–
> запихали всю запись в один поток, InnoDB теперь упирается в одно ядро Я думал запись всегда упирается в диск.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #32, #47, #77

27. Сообщение от pashev.ru (?), 24-Авг-22, 11:59	+1 +/–
Бггг :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

29. Сообщение от Онаним (?), 24-Авг-22, 12:19	–2 +/–
Там вакуумить регулярно уже не надо с (авто)блокировкой? Когда будет не надо - приходите.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #74

30. Сообщение от Онаним (?), 24-Авг-22, 12:20	+/–
Не, они изнасиловали флашер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

31. Сообщение от Онаним (?), 24-Авг-22, 12:20	+/–
ZFS под DB? Мсье знает толк в извращениях.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #34

32. Сообщение от Онаним (?), 24-Авг-22, 12:21	+/–
Смотря какой диск. В full-flash SAN оно точно не упирается, но объёмы здоровые, да и трафик между SAN и серверами сжатие жёстко сокращает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

33. Сообщение от Онаним (?), 24-Авг-22, 12:23	+/–
В Оракле таки хватило мозгов не закатывать солнце назад вручную.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

34. Сообщение от Аноним (34), 24-Авг-22, 12:47	–4 +/–
А что не так? // b.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #36

35. Сообщение от Аноним (35), 24-Авг-22, 13:48	–3 +/–
"MariaDB - это лучшая база которую я когда либо видел". (c) Альберт Эйнштейн
Ответить | Правка | Наверх | Cообщить модератору

36. Сообщение от Онаним (?), 24-Авг-22, 14:05	+1 +/–
Выше всё описано, что не так, ну да ладно. + CoW ну никак с логикой журналирования современных RDBMS не вяжется. Двойная работа + слишком мелкая запись + костыльный O_DIRECT + костыльный f(data)sync. У ZFS ещё получается аж тройное кеширование - буферный пул - системный кеш - зил-запорожец.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #42, #67, #75

37. Сообщение от Аноним (37), 24-Авг-22, 14:06	+/–
10.6 это LTS зачем с него перекатываться? 0_o
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #43

38. Сообщение от TydymBydym (?), 24-Авг-22, 14:08	+4 +/–
Всё верно. Эту цитату ошибочно приписывают Ленину, хотя написал это Маркс в одном из своих писем к Энгельсу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #80

39. Сообщение от 1 (??), 24-Авг-22, 14:14	+1 +/–
Тогда быстро ресурс прикроют за экстремизм и разжигание к маководам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #55, #72

40. Сообщение от Аноним (40), 24-Авг-22, 14:43	+2 +/–
гамно,не нужно и название тоже гамно, ведь есть человеческий mysql
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #44

42. Сообщение от Аноним (34), 24-Авг-22, 15:12	+/–
Что почитать на тему ZFS+DB? Знаю одного крупного клиента с ZFS+Postgres - нормально себе живут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #46, #61

43. Сообщение от hefenud (ok), 24-Авг-22, 15:14	+1 +/–
На некоторых проектах бывают дурные заказчики, которые могут следить за версиями используемого ПО и требовать что бы все было свежим по мажорной версии И такое бывает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

44. Сообщение от hefenud (ok), 24-Авг-22, 15:19	+1 +/–
> гамно,не нужно и название тоже гамно, ведь есть человеческий mysql Я тебе ща шаблон порву Названия MaxDB, MySQL и MariaDB даны одним человеком и созданы по одному принципу Название его ПО начинается с имен его детей(сын Max и дочери My и Maria)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #51, #53

46. Сообщение от Роман (??), 24-Авг-22, 15:40	+/–
> Что почитать на тему 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.../ )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

47. Сообщение от Роман (??), 24-Авг-22, 15:42	+/–
>> запихали всю запись в один поток, InnoDB теперь упирается в одно ядро > Я думал запись всегда упирается в диск. Тогда бы всякие io_uring не прикручивали к XFS. Тем у кого диски быстрые, актуально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

48. Сообщение от Juha (ok), 24-Авг-22, 15:51	+1 +/–
Что там с 9 на 13 без проблем переехать можно уже?? Или как обычно с бубнами?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #50, #52

50. Сообщение от letsmac (ok), 24-Авг-22, 16:12	+1 +/–
С бубнами любую версию. Но не так уж сложно играть то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

51. Сообщение от Аноним (51), 24-Авг-22, 16:24	+3 +/–
> Maria по такой логике эта мария похожа на наимерзейшего тюленя
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

52. Сообщение от 1 (??), 24-Авг-22, 17:24	+/–
Можно подумать в MySQL без бубнов можно с 5 на 8 переехать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #54

53. Сообщение от 1 (??), 24-Авг-22, 17:26	+/–
И всё на продажу
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

54. Сообщение от penetrator (?), 24-Авг-22, 18:38	+/–
можно, вообще без проблем, если не зависишь от чего-то deprecated
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #68

55. Сообщение от penetrator (?), 24-Авг-22, 18:41	+/–
opennet.org?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #70

58. Сообщение от penetrator (?), 24-Авг-22, 18:44	+/–
1) а если я не использую сжатие? 2) если это одно ядро ну очень быстрое? 3) и что там с перконой?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #62, #63

60. Сообщение от Аноним (60), 24-Авг-22, 22:11	+/–
Кусок говна, хуже Percona MySQL 8.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #64

61. Сообщение от Онаним (?), 24-Авг-22, 22:38	+/–
После слова postgres можно не продолжать. Пусть себе живут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

62. Сообщение от Онаним (?), 24-Авг-22, 22:38	+/–
1) тогда тебе это не нужно 2) таких не бывает 3) не нужно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

63. Сообщение от Онаним (?), 24-Авг-22, 22:39	+/–
Впрочем, в п.1 всё равно есть риск упереться если база пишется/модифицируется большими блоками.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #65

64. Сообщение от Онаним (?), 24-Авг-22, 22:40	+1 +/–
К сожалению да. Начиная с 10.6 что-то у них сломалось. Не в движке. В подходах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

65. Сообщение от penetrator (?), 25-Авг-22, 00:08	+/–
SSD хранилище, блобы внутри базы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

67. Сообщение от Роман (??), 25-Авг-22, 03:26	–1 +/–
> Выше всё описано, что не так, ну да ладно. > + CoW ну никак с логикой журналирования современных RDBMS не вяжется. > Двойная работа + слишком мелкая запись + костыльный O_DIRECT + костыльный f(data)sync. > У ZFS ещё получается аж тройное кеширование - буферный пул - системный > кеш - зил-запорожец. Так то да, но да и хрен с ним [в этом конкретном месте] - Double write отключен. Там еще и raid0 под мускулем [силами ZFS]. Мастером стать этому серверу не грозит, а Н или даже М денег экономит на диски поменьше, чтение параллелит, репликация даже местами быстрее чем на "нормальном" слейве с XFS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

68. Сообщение от BuildPrice (?), 25-Авг-22, 07:18	+1 +/–
>> если не зависишь Bggg
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

69. Сообщение от john_erohin (?), 25-Авг-22, 08:50	+/–
> BTRFS пробовал тоже смеюсь над этим dba в голос. рекомендации отключать журнал и write barrier на ext4 (где лежит база) прошли мимо вас или просто не были осознаны ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #71, #76, #81

70. Сообщение от john_erohin (?), 25-Авг-22, 09:00	+1 +/–
opennet.i2p opennetматьперематьтудасюда.onion
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #84

71. Сообщение от Аноним (71), 25-Авг-22, 09:06	+/–
Если отключить журнал на ext4, она работает раз в 100 медленнее. Это ничего? Да и без барьеров она точно навернётся на следующей же панике (даже writeback устраивает лисец котёнку). Я больше поверю в то, что btrfs можно настроить, чем в использование ext4 таким образом (гуглу можно, у него свои собственные возможности).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #73

72. Сообщение от Аноним (72), 25-Авг-22, 11:47	+/–
> ... и разжигание к маководам. и к растоманам
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

73. Сообщение от john_erohin (?), 25-Авг-22, 13:38	+/–
> Если отключить журнал на ext4, она работает раз в 100 медленнее. 1) под какой нагрузкой ? 2) почему ? я не вижу оснований. > Да и без барьеров она точно навернётся на следующей же > панике я что-то давно не видел кернел паников. может потому что стабильное ядро с выкинутым мусором, а может потому что железо проверенное. > Я больше поверю в то, > что btrfs можно настроить, вера - это вопрос религиозный (а в случае btrfs похоже что тоталитарно-сектантский).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #82

74. Сообщение от Аноним (74), 25-Авг-22, 14:48	–1 +/–
О, знатока сразу видно. Знаток, а зачем в Слоне автовакуум вообще? Поделитесь соображениями. Да, и что он "блокирует"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #83

75. Сообщение от Аноним (74), 25-Авг-22, 14:57	+/–
CoW и WAL ортогональны. Ни какой "двойной работы" в их сочетании нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

76. Сообщение от Аноним (74), 25-Авг-22, 14:59	+/–
А зачем вообще все эти синхронные WAL-ы? Пустая трата ресурсов. Рифовая запись, бэкапы? Ну нафиг, железо же сверхстабильное и надёжное, сбоев не даёт никогда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

77. Сообщение от Аноним (74), 25-Авг-22, 15:04	+/–
Запись упирается в странный вопрос -- а нужно ли это писать куда-то, кроме как в память. Чаще всего проблема с И/О в ничем не обоснованной избыточной волатильности буферных кэшей. Когда так настроено, что чекпоинт рубит чуть ли не без остановки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

80. Сообщение от PnD (??), 26-Авг-22, 10:54	+/–
"Эрих и Мария Ремарк в гостях у братьев Салтыкова и Щедрина.jpg"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

81. Сообщение от Онаним (?), 26-Авг-22, 17:10	+/–
> отключать журнал и write barrier на ext4 (где лежит база) Да вы, я смотрю, матёрый камикадзе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

82. Сообщение от Онаним (?), 26-Авг-22, 17:12	+/–
Ну с журналом _данных_ (который обычно и так того) я ещё готов согласиться. Выключение журнала метаданных убьёт вам структуру базы в случае краша системы во время "атомарного" изменения структуры (перемещения файлов например при DDL). Но выключение write barrier. Oh my god. Это прямой путь к потере конзистентности при ЛЮБЫХ крашах, потому что при этом fsync/fdatasync не дают никакого понимания о том, что реально на диск упало, и в каком порядке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

83. Сообщение от Онаним (?), 26-Авг-22, 17:18	–1 +/–
Давай, Знаток, расскажи, что делает автовацуум в конце операции, когда обкусывает блоки. И как себя ведёт, когда в этот момент идёт вставка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

84. Сообщение от Аноним (-), 29-Авг-22, 18:29	+/–
Люто бешено плюсую Джона Ерохина!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

85. Сообщение от TydymBydym (?), 07-Окт-22, 01:38	+/–
> Конечно, лору это помогло. А, хотя, подождите, не помогло. Еще как помогло. Там теперь тихо, как на кладбище...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема