The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Один из разработчиков MySQL раскритиковал проект и рекомендовал использовать PostgreSQL, opennews (??), 06-Дек-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


128. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от Онаним (?), 06-Дек-21, 20:44 
Мультимастер - это не про производительность. Это про возможность продолжить писать в условиях полного отказа одного из мастеров. Пусть даже и с потерей части транзакций.

А для бОльших гарантий есть синхронный мультимастер, Galera Cluster называется.

Ответить | Правка | Наверх | Cообщить модератору

138. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +1 +/
Сообщение от ыы (?), 06-Дек-21, 21:01 
>Это про возможность продолжить писать в условиях полного отказа одного из мастеров

В самом деле? Кто бы мог подумать ...

На самом деле все транзакции писавшиеся на отказавшем мастере откатываются... и все что не дошло до другого мастера тоже откатывается. Вы же не зафиксируете половину атомарной записи, правда? :)

Поэтому с точки зрения "продолжать писать при отказе" - мультимастер ничем не отличается от обычного переключения слэйва на праймори...

Ответить | Правка | Наверх | Cообщить модератору

145. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –1 +/
Сообщение от Онаним (?), 06-Дек-21, 21:41 
Э-э-э, вы точно себе представляете, как репликация работает?
Я вижу, что нет.
Ответить | Правка | Наверх | Cообщить модератору

176. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +1 +/
Сообщение от funny.falcon (?), 07-Дек-21, 08:35 
Какая репликация? Синхронная? Асинхронная? Синхронная с кворумом? На протоколе консенсуса?
Ответить | Правка | Наверх | Cообщить модератору

178. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –1 +/
Сообщение от Онаним (?), 07-Дек-21, 09:24 
Та, которая обсуждается. Но это слишком сложно, понимаю.
Ответить | Правка | Наверх | Cообщить модератору

181. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от funny.falcon (?), 07-Дек-21, 09:47 
Видимо, для вас действительно сложно.
Ответить | Правка | Наверх | Cообщить модератору

146. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –1 +/
Сообщение от Онаним (?), 06-Дек-21, 21:47 
Ну и я же не зря написал: с потерей части транзакций. Если потеря части данных не вызывает проблем. Для всякой негарантированной статистики - более чем.

Если у нас нет строгих требований к упорядоченности - мы ещё и на любой мастер писать можем, да, будет лаг синхронизации, но см. в начало строчки.

Если нам нужен мульти-мастер с синхронностью и откатом - берём галеру. Там да, не завершённая транзакция откатывается со всех узлов. Но при этом нам не нужно ничего "переключать" - как только транзакция упавшего мастера откатится, следующие будут выполнены. Более того, мы можем на любой мастер писать.

Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

213. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от Наме (?), 07-Дек-21, 13:37 
Если нужен "мультимастер", то берём Oracle RAC, а БД размещаем поверх ceph.
Ответить | Правка | Наверх | Cообщить модератору

173. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +2 +/
Сообщение от leap42 (ok), 07-Дек-21, 08:06 
>> Мультимастер - это не про производительность. Это про возможность продолжить писать в условиях полного отказа одного из мастеров. Пусть даже и с потерей части транзакций.

Вы не слушайте того кто вам такое говорит, он вообще не шарит.  Когда primary отказывает, ближайший standby становится мастером сам. Всё. Почему это лучше мультимастера? - Очень легко избежать split brain. С асинхронным мультимастером избежать split brain вообще не всегда возможно - вопрос только "когда". Синхронный мультимастер ставит на колени производительность при географическом удалении нод в 100%, и почти всегда даже если они рядом.

Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

177. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  +/
Сообщение от funny.falcon (?), 07-Дек-21, 08:41 
Согласен на 99.99%

Мультимастер действительно более живуч. Но действительно тормознее.

Практически ни кому живучесть мультимастера не нужна. Время переключения реплики - обычно меньше 1 минуты (чаше всего, 10-20 секунд). Пять переключений в год - это доступность 99.999%. Этого достаточно даже для маркетплейсов и банков (хоть они и заявляют шесть девяток, но рады и пяти девяткам).

Ответить | Правка | Наверх | Cообщить модератору

214. "Один из разработчиков MySQL раскритиковал проект и рекомендо..."  –2 +/
Сообщение от Наме (?), 07-Дек-21, 13:39 
Наоборот мульти-мастер это про производительность. Просто единственный реализованный нормальный мультимастер это RAC, где энное кол-во экземпляров работают с одним набором файлов данных (которые сами могут быть пространственно размазаны поверх сетевой фс). А галера эта муть какая-то.
Ответить | Правка | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру