| |
| |
| |
| 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х, чтобы придерживаться ещё старомодной этики, которая приводит к ошибкам в реализация уже серьёзных задач.
Я привёл стандартные механизмы мультимастера, автор же реализует схему, о которой разработчики посгрес даже не догадываются, т.е этот путь костылинг с нарушением логики работы посгрес в целом, при том костылинг не имеющий под собой никакого зерна оправдания внедрения, ибо он многократно сложнее стандартных механизмов
| | |
|
|
|
|
| 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.
| | |
|
| |
| 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 - это не репликация в постхрюках.
| | |
| |
| |
| 6.33, Онаним. (?), 23:10, 21/09/2022 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
Стандартный нечётный арбитраж с самоустранением (остановкой операций, не обязательно полностью, можно до момента восстановления кворума) нодами, не имеющими кворума. Надёжнее - с дополнительным посредником арбитража, который расположен не на нодах и не на стыках между ними, при правильной конфигурации становится возможен вторичный кворум, и количество нод вполне может быть и чётным без особых последствий, главное, чтобы не было локационного сплита 1/2. Единственным существенным моментом при этом является необходимость предварительной блокировки операций записи, чтобы не дать провести запись в случае потери кворума.
| | |
| |
| 7.35, НамНам (?), 23:55, 21/09/2022 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
> Стандартный нечётный арбитраж с самоустранением (остановкой операций, не обязательно
> полностью, можно до момента восстановления кворума) нодами, не имеющими кворума. Надёжнее
> - с дополнительным посредником арбитража, который расположен не на нодах и
> не на стыках между ними, при правильной конфигурации становится возможен вторичный
> кворум, и количество нод вполне может быть и чётным без особых
> последствий, главное, чтобы не было локационного сплита 1/2. Единственным существенным
> моментом при этом является необходимость предварительной блокировки операций записи,
> чтобы не дать провести запись в случае потери кворума.
Ну а зачем? В чём профит? Относительно простого пристрелить. "Нечёткий арбитраж" -- простите, ржал. Вы на "нечёткий арбитраж" в типично сложных случаях потратите астрономически больше времени, чем просто всё вырубить. И, снова, возращаемся к адекватности угадывания. А угадывание -- всегда угадывание. Но одно дело угадывать как лучше что-то сделать, не теряя ничего, кроме времени, чем угадывать: потерять даные... или не потерять. Причём, ладно бы был выбор, -- потерять немножко данных, но выиграть во времени исполнения -- но нет же -- вы предлагает потерять неизвестно сколько времени взамен на потерять... неизвестно сколько данных )))) Хреновый выбор.
| | |
|
|
| |
| |
| 7.36, Аноним (30), 10:44, 22/09/2022 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
А при чём тут репликация? Описанное решение как раз без репликации. Репликация подразумевает, что у вас есть н-узлов, данные на которых идентичны (строго или "в конце концов"). Т.е. каждый узел с экземпляром обладает своей репликой данных, с которой и работает. Тут же, как я понял, узлы с экземпляром используют одни и те же данные, доступ к которым разделён по времени.
| | |
|
|
|
|
|
| 2.19, Аноним (20), 18:17, 19/09/2022 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
> Садо-мазо. По набору компонент.
> "Под нагрузкой данное решение не проверялось" - т.е. теория ради теории.
Набор компонентов один из наиболее тиражных. Большая часть отказоустойчивых кластеров со Слоном реализованы либо на стеке коросинка с писмэйкером, либо на repmrg. Чуть меньше на патрони. При этом именно коросинк с писмэйкером позволяют реализовать сколь угодно сложные и изощрённые решения. Если не стоит задача делать master-master.
| | |
| |
| 3.26, Онаним. (?), 22:15, 20/09/2022 [^] [^^] [^^^] [ответить] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– | |
> Большая часть отказоустойчивых кластеров со Слоном реализованы либо на стеке коросинка с писмэйкером, либо
Вот именно поэтому я ко всему этому счастью (постхрюку) близко не подхожу.
Сколь угодно сложные и изощрённые решения позволяет MySQL и его вариации. ВПЛОТЬ до master-master.
Без всяких коросинков. Или с ними, если хочется извращаться.
Что же до задачи - на коросинках кросс-дц с парой ms делеев уже проблема.
| | |
|
|
| 1.46, Легивон (?), 10:57, 15/03/2023 [ответить] [﹢﹢﹢] [ · · · ] [п©Б∙╗ п©Б∙╙п©Б∙╛п©Б∙╒п©Б∙ёя▐Б■─п©Б∙÷я▐Б■▄п©Б∙╛я▐Б■─я▐Б■░]
| +/– |
А какой смысл в кластерной файловой системе? Сэкономить 50% места и в результате получить рост латенси (читай IOPS) в 100 раз из-за сети? Или сколько у вас получилось если учитывать что базовый сервер с SSD.
В случае с обычной master-slave репликацией и тулзой сбоку переключающей мастера (patroni, stolon, repmgr и т.д.) с реплик еще и читать можно (большинству типовых запросов типовых приложений не важна консистентность) получая производительность х3.
Если суммировать все потери то статья про то как на ровном месте сделать постгрес в 10 раз медленнее, а конфигурацию запутанее.
| | |
|
