| 1.2, Олег (??), 19:40, 12/09/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Тот момент когда вместо типовых решений используют лютый костылинг, после чего имея кучу анального с... Са.
| | |
| |
| |
| |
| 4.5, vasiukoff (?), 14:49, 14/09/2022 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Определили бы задачу вначале чего хотите
> Если просто master-master то вам https://www.percona.com/blog/2020/06/09/multi-master-replication-solutions-for
> Если поиграться с пцмаркерами, бекапами и неработающими БД то пожалуйте инструкции из
> статьи, а еще совет сразу для пущего эффекта в докер-кубер это
> завернуть
Олег,
Я ничего не имею против критики, статей на английском языке и конкретно Вас.
Но мой вопрос был в том, чтобы Вы показали свою статью на русском языке, если уж критикуете.
Я в таких случаях либо в частной беседе предлагаю свои правки автору, либо ссылаюсь на то что делал сам.
| | |
| |
| 5.6, Олег (??), 19:13, 14/09/2022 [^] [^^] [^^^] [ответить]
| +/– | |
Из моей практики тот костылинг, что предлагает автор статьи, приводит к непонятным последствиям.
Из моего жизненного опыта, мы живём не в 90х, чтобы придерживаться ещё старомодной этики, которая приводит к ошибкам в реализация уже серьёзных задач.
Я привёл стандартные механизмы мультимастера, автор же реализует схему, о которой разработчики посгрес даже не догадываются, т.е этот путь костылинг с нарушением логики работы посгрес в целом, при том костылинг не имеющий под собой никакого зерна оправдания внедрения, ибо он многократно сложнее стандартных механизмов
| | |
| |
| 6.7, casm (ok), 11:47, 15/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
 В статье описывается не multi master, в примере выше СУБД работает только на одном узле, при сбое процессов/железа автоматически переезжает на рабочий узел. Это open source аналог oracle rac one node.
| | |
| |
| |
| 8.10, casm (ok), 20:15, 15/09/2022 [^] [^^] [^^^] [ответить] | +2 +/– | Если упал сервер, то там никаких кешей уже нет Pacemaker запускает процесс post... текст свёрнут, показать | | |
|
|
| 6.13, Онаним. (?), 11:50, 17/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
Абсолютно да.
Причём этот костылинг чреват в случаях развала сети, а не падения ноды.
| | |
| 6.22, Аноним (20), 18:46, 19/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Я привёл стандартные механизмы мультимастера
Да, забавно. Из перечисленного более-менее потребен только BDR, но он платный. И, опять же, его внедрение происходит поверх repmgr или всё того же писмэйкера.
| | |
|
|
| 4.18, Аноним (20), 18:12, 19/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
Олег, а вы сами какое угодно master-master-решение внедряли/эксплуатировали, пусть и не на Слоне, а?
| | |
|
|
|
| 1.8, casm (ok), 11:52, 15/09/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ocfs2 лучше монтировать с опцией coherency=full - так медленнее, но надёжнее.
| | |
| |
| 2.15, Онаним. (?), 11:58, 17/09/2022 [^] [^^] [^^^] [ответить]
| +/– | |
> Ocfs2 лучше монтировать с опцией coherency=full - так медленнее, но надёжнее.
coherency=full так-то дефолт
Для файлов active-standby, а особенно DBMS - всё правильно, coherency full проложит мелкую запись в лог в разы.
| | |
|
| 1.11, Dan (??), 21:25, 15/09/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 the same thing can be done using postgres streaming replication, without shared FS. there is pacemaker postgres resource, that can take care about node promotion from slave to master. I did it for 3 nodes cluster - 1 active 2 stand-by for zabbix db with timescaledb extension, DB size was close to 2Tb.
| | |
| |
| 2.24, Аноним (20), 18:56, 19/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
> the same thing can be done using postgres streaming replication, without shared
> FS. there is pacemaker postgres resource, that can take care about
> node promotion from slave to master. I did it for 3
> nodes cluster - 1 active 2 stand-by for zabbix db with
> timescaledb extension, DB size was close to 2Tb.
Streaming repl needs two time more space.
| | |
|
| 1.12, Онаним. (?), 11:49, 17/09/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Садо-мазо. По набору компонент.
"Под нагрузкой данное решение не проверялось" - т.е. теория ради теории.
| | |
| |
| 2.14, Онаним. (?), 11:55, 17/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
- Коросинк развалится там, где возможны непредсказуемые делеи, т.е. решение для двух соседних стоек ДЦ
- Pacemaker требует STONITH, а реальный STONITH ныне - это очень редкая вещь. Всякие псевдо-варианты на уровне тушения виртуалок встанут колом, как только развалится менеджовая сеть, и когда это всё соберётся взад (скорее всего с раздельным написанием первой буквы) - результат непредсказуем, т.е. опять же максимум годно для полутора стоек в одном ДЦ
- Из реально работающего cross-DC здесь OCFS2, но её тоже надо уметь готовить - никаких коросинков с пацемакерами, внутренний кластерный стек там достаточно вылизанный, при этом общее дисковое хранилище в качестве дополнительного арбитра работает железно
В итоге не проще ли взять MySQL с асинхронной репликацией и не извращаться?
В худшем случае - зайдёт Galera с синхронным коммитом.
| | |
| |
| 3.21, Аноним (20), 18:36, 19/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
> - Коросинк развалится там, где возможны непредсказуемые делеи, т.е. решение для двух
> соседних стоек ДЦ
Вы удивитесь, но сбой этот как раз и есть случай "непредсказуемого делея". Подобные схемы и нужны, чтобы в случае "непредсказуемого делея" поднять новый мастер.
> - Pacemaker требует STONITH
Любые схемы с транзакциями требуют STONITH.
> В итоге не проще ли взять MySQL с асинхронной репликацией и не
> извращаться?
> В худшем случае - зайдёт Galera с синхронным коммитом.
Если данные не важны и модель данных уровня какого-нибудь web-проекта, где данные и время ничего не стоят, да.
| | |
| |
| 4.25, Онаним. (?), 22:12, 20/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
- Любые схемы с транзакциями требуют STONITH.
Нет.
- Если данные не важны и модель данных уровня какого-нибудь web-проекта, где данные и время ничего не стоят, да.
Надувание щёк не предмет для обсуждения однозначно. И да, возможно тут просто незнание место быть имеет. Потому что репликация в MySQL - это не репликация в постхрюках.
| | |
| |
| 5.30, Аноним (30), 15:11, 21/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
> - Любые схемы с транзакциями требуют STONITH.
> Нет.
Было бы интересно почитать что-нибудь о том, как обходиться без STONITH.
| | |
| |
| 6.33, Онаним. (?), 23:10, 21/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
Стандартный нечётный арбитраж с самоустранением (остановкой операций, не обязательно полностью, можно до момента восстановления кворума) нодами, не имеющими кворума. Надёжнее - с дополнительным посредником арбитража, который расположен не на нодах и не на стыках между ними, при правильной конфигурации становится возможен вторичный кворум, и количество нод вполне может быть и чётным без особых последствий, главное, чтобы не было локационного сплита 1/2. Единственным существенным моментом при этом является необходимость предварительной блокировки операций записи, чтобы не дать провести запись в случае потери кворума.
| | |
| |
| 7.35, НамНам (?), 23:55, 21/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Стандартный нечётный арбитраж с самоустранением (остановкой операций, не обязательно
> полностью, можно до момента восстановления кворума) нодами, не имеющими кворума. Надёжнее
> - с дополнительным посредником арбитража, который расположен не на нодах и
> не на стыках между ними, при правильной конфигурации становится возможен вторичный
> кворум, и количество нод вполне может быть и чётным без особых
> последствий, главное, чтобы не было локационного сплита 1/2. Единственным существенным
> моментом при этом является необходимость предварительной блокировки операций записи,
> чтобы не дать провести запись в случае потери кворума.
Ну а зачем? В чём профит? Относительно простого пристрелить. "Нечёткий арбитраж" -- простите, ржал. Вы на "нечёткий арбитраж" в типично сложных случаях потратите астрономически больше времени, чем просто всё вырубить. И, снова, возращаемся к адекватности угадывания. А угадывание -- всегда угадывание. Но одно дело угадывать как лучше что-то сделать, не теряя ничего, кроме времени, чем угадывать: потерять даные... или не потерять. Причём, ладно бы был выбор, -- потерять немножко данных, но выиграть во времени исполнения -- но нет же -- вы предлагает потерять неизвестно сколько времени взамен на потерять... неизвестно сколько данных )))) Хреновый выбор.
| | |
|
|
| 5.31, Аноним (30), 15:13, 21/09/2022 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Потому что репликация в MySQL - это не репликация в постхрюках.
А что не так с репликацией в Слоне?
| | |
| |
| |
| 7.36, Аноним (30), 10:44, 22/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
А при чём тут репликация? Описанное решение как раз без репликации. Репликация подразумевает, что у вас есть н-узлов, данные на которых идентичны (строго или "в конце концов"). Т.е. каждый узел с экземпляром обладает своей репликой данных, с которой и работает. Тут же, как я понял, узлы с экземпляром используют одни и те же данные, доступ к которым разделён по времени.
| | |
|
| 6.34, НамНам (?), 23:46, 21/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
А как-то более предметно? В Слоне репликация работает. Она надёжно наблюдаема. И крайне легка в настройке. Что из этого вы способны аргументировано оспорить?
| | |
| |
| |
| 8.42, Аноним (30), 11:09, 23/09/2022 [^] [^^] [^^^] [ответить] | +/– | Не понял вас, не понял, что значит в изменение схемы Понятие схемы очень уж м... текст свёрнут, показать | | |
|
|
|
|
|
|
| 2.17, Онаним. (?), 12:02, 17/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
Ну и да, поскольку у нас тут простой active-standby - можно тупо обойтись keepalived и монтированием разделяемого раздела на той ноде, которая должна живой стать, даже с OCFS2 не извращаясь.
| | |
| 2.19, Аноним (20), 18:17, 19/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
> Садо-мазо. По набору компонент.
> "Под нагрузкой данное решение не проверялось" - т.е. теория ради теории.
Набор компонентов один из наиболее тиражных. Большая часть отказоустойчивых кластеров со Слоном реализованы либо на стеке коросинка с писмэйкером, либо на repmrg. Чуть меньше на патрони. При этом именно коросинк с писмэйкером позволяют реализовать сколь угодно сложные и изощрённые решения. Если не стоит задача делать master-master.
| | |
| |
| 3.26, Онаним. (?), 22:15, 20/09/2022 [^] [^^] [^^^] [ответить]
| +/– | |
> Большая часть отказоустойчивых кластеров со Слоном реализованы либо на стеке коросинка с писмэйкером, либо
Вот именно поэтому я ко всему этому счастью (постхрюку) близко не подхожу.
Сколь угодно сложные и изощрённые решения позволяет MySQL и его вариации. ВПЛОТЬ до master-master.
Без всяких коросинков. Или с ними, если хочется извращаться.
Что же до задачи - на коросинках кросс-дц с парой ms делеев уже проблема.
| | |
| |
| 4.29, Аноним (30), 15:07, 21/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
Про MySQL ничего сказать не могу. Мой опыт в пользу того, чтобы MySQL не применять ни для чего сложнее регистратора событий.
И нет, для MySQL нет и близко решений master-master такого уровня, которые есть для Слона.
| | |
|
|
|
| 1.23, Аноним (20), 18:49, 19/09/2022 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Похоже на одноузловой РЭК. Общий кластер БД. Экземпляры монтируют его в разное время. Вполне жизненно.
| | |
| |
| 2.27, Онаним. (?), 22:17, 20/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
Не совсем понятно на фига в этой схеме коросинк и прочее.
Обычного keepalived и ocfs2 с арбитрацией на разделяемой хранилке будет более, чем достаточно.
| | |
| |
| 3.28, Онаним. (?), 22:18, 20/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
(причём с арбитрацией на хранилке даже в конфигурации с двумя нодами будет работать, если нужен здоровый минимализм)
| | |
| 3.37, Аноним (37), 14:48, 22/09/2022 [^] [^^] [^^^] [ответить]
| +/– |
Писмэйкер и коросинком позволяют сделать стэк отказа сколь угодно глубоким. Можно в этот пирог запихнуть реакцию на что угодно, хоть на фазу луны, если это нужно. Другое дело, нужно ли. Но другой вопрос.
| | |
| |
| 4.40, Онаним. (?), 00:16, 23/09/2022 [^] [^^] [^^^] [ответить]
| +/– | |
Писмэйкер и коросинком позволяют сделать проникновение граблей сколь угодно глубоким
Fixed.
| | |
| |
| 5.44, Аноним (30), 11:19, 23/09/2022 [^] [^^] [^^^] [ответить]
| +/– | |
> Писмэйкер и коросинком позволяют сделать проникновение граблей сколь угодно глубоким
Ну и это тоже. Это тёмная сторона гибкости и функциональности.
| | |
|
|
|
|
| 1.46, Легивон (?), 10:57, 15/03/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А какой смысл в кластерной файловой системе? Сэкономить 50% места и в результате получить рост латенси (читай IOPS) в 100 раз из-за сети? Или сколько у вас получилось если учитывать что базовый сервер с SSD.
В случае с обычной master-slave репликацией и тулзой сбоку переключающей мастера (patroni, stolon, repmgr и т.д.) с реплик еще и читать можно (большинству типовых запросов типовых приложений не важна консистентность) получая производительность х3.
Если суммировать все потери то статья про то как на ровном месте сделать постгрес в 10 раз медленнее, а конфигурацию запутанее.
| | |
|