Ну, во-первых, там совершенно очевидно, что по правилам русского языка будет средний пол (называть таких людей в мужском роде это жуткий сексизм), во-вторых у всех людей другой набор хромосом, чем у меня, а в-третьих "иное" и "другое" это синонимы, но "другое" это как-то не по-русский. Ничего не имею против людей с мозаицизмом по половым хромосомам, но вот любовь к Кончите Вурст не является признаком цивилизованности. Тут вы ошибаетесь.
Тогда бы не было интриги. :) А как же интриги и расследования?
Вы абсолютно правы обоим вопросам. То как можно посмотреть размер столбца, я потом и сам так посмотрел, когда увидел, что размеры таблиц совпадают. То что выигрыш может появится в массивах и во вложенных row, вы тоже правы. Но с другой стороны это довольно нетипично для enumeration оказаться в массиве.
В общем спасибо за ценный комментарий прекрасно дополняющий эту статью.
Как я понял они сделали то, о чём я и написал постом выше, а именно запустили jepsen тест и параллельно
We introduced a number of faults during our testing process, including process pauses, crashes, network partitions, clock skew, and membership changes.
Ну что тут скажешь. Я проверяю работоспособность БД очень примитивно, на мастере пишу в таблицу текущее время, на реплике считываю. Если вместе с этим запустить параллельно jepsen тест, то можно будет сказать, что тестирование гораздо более тщательное. Но не буду добавлять в свои скрипты, это неоправданно их усложнит. Думаю желающие, кому это будет нужно, смогут сами запустить jepsen тест параллельно.
Про cockroachdb не слышал, про Postgres Pro Multi Master (неизвестной цены), читал. На сколько я помню, они реализовали мультимастер на распределенных транзакциях, причем трехфазных. Выглядит это круто, в маркетинговых проспектах, но вы правы, вызывает большой скепсис для использования при высоких нагрузках. Во-первых интуиция подсказывает что на таких распределенных транзакциях будет сильно просаживаться производительность. А во-вторых при высоких нагрузках можно ожидать ошибки и откаты транзакций из-за того, что распределенные транзакции будут конфликтовать друг с другом. Ну а поскольку решение небесплатное, то никто его мне покупать не будет только для того, чтобы я погонял на нём тесты.
Почитал. jepsen придумывался для других задач. Для начала он зачем-то по SSH заходит на все узлы распределенной БД, потом начинает одновременно в них что-то писать, потом сверяет результат с тем, что он ожидает. Он тестирует распределенные БД на целостность данных при конкурентной записи. Тоже полезно, но не то, что я написал. Мой тестовый стенд тестирует отказоустойчивую систему на отказоустойчивость путем имитации различных поломок на виртуалках, jepsen это не делает. Теоретический его можно было бы использовать параллельно, чтобы убедится в отсутствии искажения при работе отказоустойчивой системы. Как в упомянутом вами случае с потерей подтвержденных закоммиченных транзакций в 1м и 2м кластерах.
Выяснилось, что вы считаете Java языком веб-апплетов, вроде Флеша, а также считаете JavaScript его близким родственником (на основании того что оба используют синтаксис Си и имеют похожее название). Это просто эпично! Надеюсь, ваш босс этого не увидит, иначе ждите беды.
Как же достало ваше враньё. Нет, я так не считаю и никогда так не считал. Я такого не писал и вы осознанно врёте приписывая свой собственный бред мне. А значит и всем остальным вашим заявлениям можно не верить.
По сути это звучит так, что для того чтобы поднять кластер отказоустойчивых PostgreSQL надо поднять еще один кластер отказоустойчивых неSQL БД. :) И то как это будет работать, тут надо анализировать не сами DCS, а всю систему целиком. Например вот тут https://pgconf.ru/2020/274123
на 39й минуте лектор рисует интересную картинку. Да, картинка искусственная, и split-brain, как я понял, там не возникнет, просто демонстрация, что могут быть нюансы. Система, на самом деле, получается гораздо сложнее и как следствие гораздо сложнее анализировать её поведение при различных вариантах отказов, которых причем этих вариантов тоже будет гораздо больше.
С другой стороны то, что предлагает Pacemaker, а именно все хранить в файле XML, который синхронизируется с помощью специального протокола — мне тоже не нравится. Можно было бы и получше придумать.
Pacemaker же поддерживает исключительно VIP, который требует чтобы все сервера находились в одном сегменте сети.
Ну, да, все правильно ) хорошо ещё, что дедушку keepAlived не вспомнили )
Да нет, неправильно. Неправильное там слово "исключительно". Pacemaker универсальная модульная инфраструктура (в отличии от Patroni). Модули бывают разными. Есть модули для IP, входят в стандартную поставку. Ничего не мешает сделать модуль для dynamic dns, чтобы по аналогии с Консулом подменять DNS записи. Такое решение выглядит хуже, так как DNS много где могут кэшироваться, но не вижу тут ничего невозможного. Но поскольку сисадмины в свое время обещали оптоволокно между дата-центрами, я на эту тему не заморачивался.
Другое ограничение самого Pacemaker, что для работы ему была нужна плоская сеть. Возможно оно возникло в те времена, когда Pacemaker использовал бродкастовый трафик для обнаружения узлов. Сейчас он может использовать и уникастовый (когда явно прописываешь IP узлов в конфиге) и мультикастовый. Не тестировал в неплоской сети, но не вижу причин, чтобы так не работало.
В остальном — да, патрони — вероятно лучшее решение для создания постгрес кластеров, но это не означает, что оно идеальное.
Ну тут смотря по каким критериям оценивать. И у Pacemaker и у Patroni есть свои фичи. Что-то у одного лучше сделано, что-то у другого. В зависимости от того, кто считает какие фичи более важными, а недостатки более незначительными, для того и будет такое решение лучшим. Согласен с тем, что идеала до сих пор нет. И решения по управлению репликацией postgresql не ограничиваются pacemaker, repmgr, patroni. Недавно я знал про STOLON и ничего не мешает появится еще каким-нибудь, пока в конкурентной борьбе не победит сильнейший. Pacemaker тут стоит особняком, потому что только он из перечисленного позиционирует себя как универсальная инфраструктура для отказоустойчивых кластеров, на базе которого можно строить такие кластера для разных сервисов и даже для объединения разных сервисов. Но эта универсальность является и его же недостатком, потому что накладывает определенные ограничения на модули. Из-за которых, например, PAF выбирает раба с наименьшим отставанием используя откровенный костыль.
Отличный вопрос. :) Да, кластера 1 и 2 могут потерять информацию об уже подтвержденных закоммиченных транзакциях. Придуманы они были потому, что "изначально у нас будет только два дата-центра". :) Так получается, что для отказоустойчивости нужна асинхронная репликация, для не потери информации синхронная, а чтобы то и то, нужно чтобы и репликация была и такая и такая. Так реализовано в кластерах 3 и 4.
Есть еще вариант, если мне память не изменяет, реализованный то ли в Patroni, то ли Repmgr (могу путать, года два назад про это читал): репликация синхронная, но когда отваливается раб переключается в асинхронную. С одной стороны такое решение очень похоже на простую асинхронную. Потому что никаких гарантий дублирования закоммиченных транзакций не будет. С другой стороны, если расчёт идет только на один отказ, то кажется, что всё не так уж и плохо. Отвалиться может либо мастер либо раб и в обоих случаях сохраниться и работоспособность и не будут потеряны подтвержденные закоммиченные транзакции.
У Sun даже был карманный компьютер, который работал на джаве еще в 90-х годах.
То что он был у Sun это не означает, что он был где-то еще. :)
Никакой специальной ориентации на веб у этого языка не предполагалось.
Да при задумывали языка, может быть, но тем не менее сходство апплетов и флешей очевидно. :) Конкуренция была за конкретную рыночную нишу.
Я прекрасно помню эти времена, т.к. я сам писал CGI скрипты ещё раньше.
На чём? Неужели на C#?
JavaScript же не имеет ни малейшего отношения к Java, по-моему это знают даже дети.
Опять демагогический приём ни имеющий ничего общего с реальностью. Сходство синтаксиса не случайно. Да и названия. :) Так что вы в очередной раз не то чтобы ошибаетесь, а осознанно вводите людей в заблуждение.
Представьте себе, SSD тоже можно монтировать как и NFS. Не знаю как в вашей компании, а в моей можно хоть 50 ТБ SSD подключать одним кликом к виртуальным машинам.
Вы опять удивительным образом не можете прочитать то, что вам не нравится. Неужели… даже не хочется называть это слово, как называется такое поведение. Я же несколько раз говорил про облака Кубернетис. Облако подразумевает несколько узлов, между которыми могут перемещаться поды. Это делается как для отказоустойчивости, так и для балансировки нагрузки. Поэтому точно так же не получится.
Мне жаль что в вашей компании так безалаберно относятся к найму сотрудников, и оттого у вас сложилось это мнение о какой-то касте ущербных "веб-разработчиков", пишущих на флеше.
А вот это было с вашей стороны особенно подло. Вы переврали мои слова, я никогда веб-разработчиков не называл и не считал ущербными. Теперь у меня такое мнение сложилось только о вас и вовсе не потому что вы называете себя "веб-разработчик". Да вы еще попытались, между делом, очернить мою компанию.
Но и пришло понимание, почему Patroni настолько популярен, не смотря на все связанные с ним неудобства. Именно что из-за очень агрессивной рекламной политики зомбирования населения, когда всё живое, имеющее альтернативное мнение тщательно вытаптывается, с использованием самых гнусных педагогических приёмов, перевирая слова оппонента и т.д. Да, это была классная провокация с вашей стороны, вы же начали
А вы не смотрели в сторону Patroni? Это популярное open source решение, основанное на той же идее кворума с использованием DCS (etcd, consul и т.п.). Успешно применяется в продакшн. Здесь на Хабре было много статей про этот проект. Я не рекламирую, просто интересно чем он не подошёл именно вам.
Это был ваш провокационный вопрос с целью развязать холивар про Patroni и провести рекламную компанию в статье, которая никакого отношения к Patroni не имеет, статья была про то как можно и искать и находить недостатки в Pacemaker. Поэтому:
Первое, завязывайте здесь с любым самопиаром и рекламой Patroni. Это оффтопик.
Второе, обратите внимание на моё предложение КиберДемону, которое я сделал ниже. Я написал инструмент, с помощью которого тестировать Pacemaker. Форкните проект, замените Pacemaker на Patroni, покажите всему миру насколько он круто работает. Разумеется показывать это надо будет на всех заявленных поддерживаемых хранилищах данных: ETCD, Consul, ZooKeeper. Это будет реальный вклад, а не пустое сотрясение воздуха громкими словами, которые все равно не предоставляется возможность проверить. Уж с вашим заявленным опытом управления тремя докторами наук переписать под Patroni будет пару раз плюнуть. Странно что вы раньше, до меня, не догадались это сделать.
А пока этого не сделаете, больше мне говорить с вами не о чем.
Извините, но ваша теория параллельной вселенной для веб-разработчиков — полная лажа. При чём тут вообще Perl и PHP?
Нет, не извиняю. Вы как-то странно читаете, не то что написано, а то что вам хочется прочитать, чтобы потом поскандалить. Вот что написано.
Веб-разработчики появились гораздо позже, произошли они от того что веб-дизайнеры, которые были по сути гуманитарии, программировали что-то для своих нужд на php, perl
Речь шла именно о том, от чего они произошли, что было началом эволюции. Когда я с этим столкнулся, это были именно что php и perl, причем php только начинал набирать обороты, видать в начала был только perl. И, конечно, флэш, я забыл его упомянуть, весь крутой фронтэнд писался на нем. Java появилась позже, причем для написания апплетов, именно как конкурент флэшу, но даже эту конкуренцию джава проиграла. ДжаваСкрипт появился после джавы как идея решать те же задачи, но без запуска апплетов и виртуальной машины. C# появился после того, как Sun подала в суд на M$, когда те в своей привычной манере стали реализовывать Java несовместимой с оригиналом Sun. Да, сейчас все сильно эволюционировало и изменилось. В конторе почти все веб-разработчики и на чём они сейчас пишут и что сейчас майнстрим я в курсе, вы го ланг забыли упомянуть, питон и руби на рельсах. :) Вы слишком молоды и слишком мало знаете, чтобы считать что из того что я пишу лажа, а что нет.
о чём вы, судя по всему, даже не подозреваете.
Опять же в силу вашей собственной ограниченности вы делаете ложные выводы что я знаю, а что нет. И приписываете это мне. Да вы правильно перечислили, какие сложности возникают в микросервисной архитектуре, собственно поэтому раньше программировали по другому, потому что так проще программировать без ошибок. Вот только мало кто умеет все эти сложности микросервисной архитектуры реализовывать без проблем. Громкие слова выучили, а нарушений data integrity сплошь и рядом. Обычно эти проблемы решаются тем, что когда устраиваются на работу стараются попасть проект который только начал разрабатываться, а когда проект доходит до прода все стремительно начинают искать новую работу. :)
Само собой все персистентные данные хранятся на дисках вне контейнера. Внутри контейнера интересен только код. Во время создания контейнера в его ФС монтируются любое количество внешних файлов, директорий и секретов. Грубо говоря, к примеру, каталог PGDATA, тейблспейсы, отдельно может быть каталог pg_wal, файл .pgpass и т.д.
Да тут вы подтвердили мои слова. А в случае продакшина исползуются облака кубернетись. Там то как вы мантируете? Сетевая файловая система? NFS? CephFS?
Хотите обновить версию сервера или может быть какой-то extension, нет ничего проще.
Да нет, есть же. Сделать то же самое, только без контейнеров, гораздо проще. :) Дебианподобные дистрибутивы и репозиторий от postgres для редхатоподобных поддерживает одновременную установку пакетов постгреса разных версий. Там достаточно просто установить пакет с новой версией и никакой возни с тем, что вы называете "нет ничего проще". :)
Холоп это военнопленный, наихудшая форма рабства на Руси. Потом так стали называть и обычных крестьян. А полным аналогом "мастэ" будет господин он же господарь. Это и было обозначение рабовладельца, которое потом перешло в обычное обращение. Собственно когда цари стали себя наименовать "господарь всея Руси" это означало что всё остальное население, включая дворян, это рабы по отношению к царю. При великих князьях такого разумеется не было.
Ну а если серьезно, почему я использовал "мастер" и "раб", потому что, понятно, английские термины, которые приняты много где, в том числе и Pacemaker, это master и slave. И если слово "мастер" по русским падежам нормально склоняется, то как "слейв" склоняется по падежам мне не понравилось.
Комментарии сильно уклонились от темы статьи. Если вы еще не поняли, то я поясню, статья была про то, как можно искать (и находить) недостатки Pacemaker. Вместо этого набежали адепты Patroni и с религиозным фанатизмом (по другому и не скажешь) стали доказывать, что Patroni самый лучший в мире. Словно я покушаюсь на ваши доходы. :)
Поэтому я предлагаю закончить совершенно неуместный здесь холивар и вернуться к теме статьи. Инструмент для тестирования Pacemaker я написал. Хороший или плохой он, можно обсуждать, то что его можно улучшать и совершенствовать (как инструмент, так и Pacemaker) это бесспорно.
Так что вместо того, чтобы сотрясать воздух эмоциональными высказываниями и давить "авторитетом", предлагаю более конструктивный путь. Форкните проект, замените ту часть, где развертывается Pacemaker на Patroni, покажите миру как все классно работает. Я за здоровую конкуренцию. Сложного там ничего нет, главные заморочки были с многооконным интерфейсом в tmux, само развертывание и тестирование достаточно очевидно. Не нравится bash? Мне он тоже не нравится. Перепишите на python или на что сочтете нужным.
Вы же понимаете, как сильно можно будет поднять бабла, если во время лекций можно будет не просто так сотрясать воздух или показывать видео, а в реальном времени показывать, что вот, происходят отказы и как система с ними борется. Или вот, система успешно преодолела 1000 отказов. (Кстати на Pacemaker я до этой цифры так и не дошел. Как уже сказал, есть чего совершенствовать. :) Для такого использования во время демонстраций, кстати, надо сохранить способность системы целиком работать на одном MacBook Pro.
Вы так говорите, как будто веб-разработчики это второй сорт.
Вы так говорите, словно я как будто бы говорю, что веб-разработчики второй сорт. :) И пытаетесь спорить со мной по тем с вашей стороны спорным моментам, которые вы же сами для меня и придумали. Нет. Если вам интересная моя действительная точка зрения, то веб-разработчики это параллельная ветвь эволюции, альтернативная цивилизация. Обычные программисты зародились где-то в середине прошлого века (если не считать Аду Байрон), перфокарты, релейные компьютеры и всё такое. Породили их инженеры, математики. Прошли свой эволюционный путь, создали свою цивилизацию, культуру, парадигмы программирования, понятия о добре и зле. Веб-разработчики появились гораздо позже, произошли они от того что веб-дизайнеры, которые были по сути гуманитарии, программировали что-то для своих нужд на php, perl и прочих языках с нестрогой типизацией, которых нормальные программисты избегали как черт ладана. Но не смотря на всю иронию и скепсис обращенный в их адрес веб-разработчики сумели доказать свою эволюционную приспособленность, главным образом тем, что они захватили и удерживают большУю часть рынка услуг и труда (а в России так и бОльшую). И заметно как тонкие клиенты повсеместно вытесняют толстые. Возникнув независимо веб-разработчики создали свою альтернативную цивилизацию, культуру, свои парадигмы. На нормальных программистов они похожи примерно так же, как головоногие на приматов. Но не смотря на всю иронию можно только уважительно относится к их способности отжимать рынок. :) Есть чему поучится, проанализировать почему так происходит.
Насчёт запуска СУБД внутри контейнеров — ну так это же просто удобно!
Когда я вижу, что сисадмины опять суетятся по утру с красными глазами, я понимаю, что у них опять проблемы с Кубернетисом. :) Это был легкая ирония, а сейчас объясню свой сарказм по поводу СУБД внутри контейнеров. Если читать документацию к докеру, там буквально на первых страницах объясняются принципы использования контейнеров. Один из них, все данные связанные с логикой работы сервиса внутри контейнера должны храниться вне контейнера, либо на серверах баз данных, либо на внешних (по отношению к контейнеру) разделах, которые в него мантируются. А в случае облаков Кубернетис с его "отказоустойчивостью" и балансировкой нагрузки тут уже, наверное, речь идет сетевых файловых системах. Но не суть важно, PostgreSQL это база данных и по самим принципам создания сервисов в контейнерах она должна быть расположена вне контейнеров. :)
Хотя я признаю, что для таких целей как разработка и тестирование виртуалки и контейнеры действительно могут быть полезны. Этот проект тому подтверждение.
Ну, во-первых, там совершенно очевидно, что по правилам русского языка будет средний пол (называть таких людей в мужском роде это жуткий сексизм), во-вторых у всех людей другой набор хромосом, чем у меня, а в-третьих "иное" и "другое" это синонимы, но "другое" это как-то не по-русский. Ничего не имею против людей с мозаицизмом по половым хромосомам, но вот любовь к Кончите Вурст не является признаком цивилизованности. Тут вы ошибаетесь.
Тогда бы не было интриги. :) А как же интриги и расследования?
Вы абсолютно правы обоим вопросам. То как можно посмотреть размер столбца, я потом и сам так посмотрел, когда увидел, что размеры таблиц совпадают. То что выигрыш может появится в массивах и во вложенных row, вы тоже правы. Но с другой стороны это довольно нетипично для enumeration оказаться в массиве.
В общем спасибо за ценный комментарий прекрасно дополняющий эту статью.
Как я понял они сделали то, о чём я и написал постом выше, а именно запустили jepsen тест и параллельно
Ну что тут скажешь. Я проверяю работоспособность БД очень примитивно, на мастере пишу в таблицу текущее время, на реплике считываю. Если вместе с этим запустить параллельно jepsen тест, то можно будет сказать, что тестирование гораздо более тщательное. Но не буду добавлять в свои скрипты, это неоправданно их усложнит. Думаю желающие, кому это будет нужно, смогут сами запустить jepsen тест параллельно.
Про cockroachdb не слышал, про Postgres Pro Multi Master (неизвестной цены), читал. На сколько я помню, они реализовали мультимастер на распределенных транзакциях, причем трехфазных. Выглядит это круто, в маркетинговых проспектах, но вы правы, вызывает большой скепсис для использования при высоких нагрузках. Во-первых интуиция подсказывает что на таких распределенных транзакциях будет сильно просаживаться производительность. А во-вторых при высоких нагрузках можно ожидать ошибки и откаты транзакций из-за того, что распределенные транзакции будут конфликтовать друг с другом. Ну а поскольку решение небесплатное, то никто его мне покупать не будет только для того, чтобы я погонял на нём тесты.
Почитал. jepsen придумывался для других задач. Для начала он зачем-то по SSH заходит на все узлы распределенной БД, потом начинает одновременно в них что-то писать, потом сверяет результат с тем, что он ожидает. Он тестирует распределенные БД на целостность данных при конкурентной записи. Тоже полезно, но не то, что я написал. Мой тестовый стенд тестирует отказоустойчивую систему на отказоустойчивость путем имитации различных поломок на виртуалках, jepsen это не делает. Теоретический его можно было бы использовать параллельно, чтобы убедится в отсутствии искажения при работе отказоустойчивой системы. Как в упомянутом вами случае с потерей подтвержденных закоммиченных транзакций в 1м и 2м кластерах.
Как же достало ваше враньё. Нет, я так не считаю и никогда так не считал. Я такого не писал и вы осознанно врёте приписывая свой собственный бред мне. А значит и всем остальным вашим заявлениям можно не верить.
По сути это звучит так, что для того чтобы поднять кластер отказоустойчивых PostgreSQL надо поднять еще один кластер отказоустойчивых неSQL БД. :) И то как это будет работать, тут надо анализировать не сами DCS, а всю систему целиком. Например вот тут
https://pgconf.ru/2020/274123
на 39й минуте лектор рисует интересную картинку. Да, картинка искусственная, и split-brain, как я понял, там не возникнет, просто демонстрация, что могут быть нюансы. Система, на самом деле, получается гораздо сложнее и как следствие гораздо сложнее анализировать её поведение при различных вариантах отказов, которых причем этих вариантов тоже будет гораздо больше.
С другой стороны то, что предлагает Pacemaker, а именно все хранить в файле XML, который синхронизируется с помощью специального протокола — мне тоже не нравится. Можно было бы и получше придумать.
Да нет, неправильно. Неправильное там слово "исключительно". Pacemaker универсальная модульная инфраструктура (в отличии от Patroni). Модули бывают разными. Есть модули для IP, входят в стандартную поставку. Ничего не мешает сделать модуль для dynamic dns, чтобы по аналогии с Консулом подменять DNS записи. Такое решение выглядит хуже, так как DNS много где могут кэшироваться, но не вижу тут ничего невозможного. Но поскольку сисадмины в свое время обещали оптоволокно между дата-центрами, я на эту тему не заморачивался.
Другое ограничение самого Pacemaker, что для работы ему была нужна плоская сеть. Возможно оно возникло в те времена, когда Pacemaker использовал бродкастовый трафик для обнаружения узлов. Сейчас он может использовать и уникастовый (когда явно прописываешь IP узлов в конфиге) и мультикастовый. Не тестировал в неплоской сети, но не вижу причин, чтобы так не работало.
Ну тут смотря по каким критериям оценивать. И у Pacemaker и у Patroni есть свои фичи. Что-то у одного лучше сделано, что-то у другого. В зависимости от того, кто считает какие фичи более важными, а недостатки более незначительными, для того и будет такое решение лучшим. Согласен с тем, что идеала до сих пор нет. И решения по управлению репликацией postgresql не ограничиваются pacemaker, repmgr, patroni. Недавно я знал про STOLON и ничего не мешает появится еще каким-нибудь, пока в конкурентной борьбе не победит сильнейший. Pacemaker тут стоит особняком, потому что только он из перечисленного позиционирует себя как универсальная инфраструктура для отказоустойчивых кластеров, на базе которого можно строить такие кластера для разных сервисов и даже для объединения разных сервисов. Но эта универсальность является и его же недостатком, потому что накладывает определенные ограничения на модули. Из-за которых, например, PAF выбирает раба с наименьшим отставанием используя откровенный костыль.
Отличный вопрос. :) Да, кластера 1 и 2 могут потерять информацию об уже подтвержденных закоммиченных транзакциях. Придуманы они были потому, что "изначально у нас будет только два дата-центра". :) Так получается, что для отказоустойчивости нужна асинхронная репликация, для не потери информации синхронная, а чтобы то и то, нужно чтобы и репликация была и такая и такая. Так реализовано в кластерах 3 и 4.
Есть еще вариант, если мне память не изменяет, реализованный то ли в Patroni, то ли Repmgr (могу путать, года два назад про это читал): репликация синхронная, но когда отваливается раб переключается в асинхронную. С одной стороны такое решение очень похоже на простую асинхронную. Потому что никаких гарантий дублирования закоммиченных транзакций не будет. С другой стороны, если расчёт идет только на один отказ, то кажется, что всё не так уж и плохо. Отвалиться может либо мастер либо раб и в обоих случаях сохраниться и работоспособность и не будут потеряны подтвержденные закоммиченные транзакции.
Спасибо, любопытно. Про jepsen не слышал, почитаю.
То что он был у Sun это не означает, что он был где-то еще. :)
Да при задумывали языка, может быть, но тем не менее сходство апплетов и флешей очевидно. :) Конкуренция была за конкретную рыночную нишу.
На чём? Неужели на C#?
Опять демагогический приём ни имеющий ничего общего с реальностью. Сходство синтаксиса не случайно. Да и названия. :) Так что вы в очередной раз не то чтобы ошибаетесь, а осознанно вводите людей в заблуждение.
Вы опять удивительным образом не можете прочитать то, что вам не нравится. Неужели… даже не хочется называть это слово, как называется такое поведение. Я же несколько раз говорил про облака Кубернетис. Облако подразумевает несколько узлов, между которыми могут перемещаться поды. Это делается как для отказоустойчивости, так и для балансировки нагрузки. Поэтому точно так же не получится.
А вот это было с вашей стороны особенно подло. Вы переврали мои слова, я никогда веб-разработчиков не называл и не считал ущербными. Теперь у меня такое мнение сложилось только о вас и вовсе не потому что вы называете себя "веб-разработчик". Да вы еще попытались, между делом, очернить мою компанию.
Но и пришло понимание, почему Patroni настолько популярен, не смотря на все связанные с ним неудобства. Именно что из-за очень агрессивной рекламной политики зомбирования населения, когда всё живое, имеющее альтернативное мнение тщательно вытаптывается, с использованием самых гнусных педагогических приёмов, перевирая слова оппонента и т.д. Да, это была классная провокация с вашей стороны, вы же начали
Это был ваш провокационный вопрос с целью развязать холивар про Patroni и провести рекламную компанию в статье, которая никакого отношения к Patroni не имеет, статья была про то как можно и искать и находить недостатки в Pacemaker. Поэтому:
Первое, завязывайте здесь с любым самопиаром и рекламой Patroni. Это оффтопик.
Второе, обратите внимание на моё предложение КиберДемону, которое я сделал ниже. Я написал инструмент, с помощью которого тестировать Pacemaker. Форкните проект, замените Pacemaker на Patroni, покажите всему миру насколько он круто работает. Разумеется показывать это надо будет на всех заявленных поддерживаемых хранилищах данных: ETCD, Consul, ZooKeeper. Это будет реальный вклад, а не пустое сотрясение воздуха громкими словами, которые все равно не предоставляется возможность проверить. Уж с вашим заявленным опытом управления тремя докторами наук переписать под Patroni будет пару раз плюнуть. Странно что вы раньше, до меня, не догадались это сделать.
А пока этого не сделаете, больше мне говорить с вами не о чем.
Нет, не извиняю. Вы как-то странно читаете, не то что написано, а то что вам хочется прочитать, чтобы потом поскандалить. Вот что написано.
Речь шла именно о том, от чего они произошли, что было началом эволюции. Когда я с этим столкнулся, это были именно что php и perl, причем php только начинал набирать обороты, видать в начала был только perl. И, конечно, флэш, я забыл его упомянуть, весь крутой фронтэнд писался на нем. Java появилась позже, причем для написания апплетов, именно как конкурент флэшу, но даже эту конкуренцию джава проиграла. ДжаваСкрипт появился после джавы как идея решать те же задачи, но без запуска апплетов и виртуальной машины. C# появился после того, как Sun подала в суд на M$, когда те в своей привычной манере стали реализовывать Java несовместимой с оригиналом Sun. Да, сейчас все сильно эволюционировало и изменилось. В конторе почти все веб-разработчики и на чём они сейчас пишут и что сейчас майнстрим я в курсе, вы го ланг забыли упомянуть, питон и руби на рельсах. :) Вы слишком молоды и слишком мало знаете, чтобы считать что из того что я пишу лажа, а что нет.
Опять же в силу вашей собственной ограниченности вы делаете ложные выводы что я знаю, а что нет. И приписываете это мне. Да вы правильно перечислили, какие сложности возникают в микросервисной архитектуре, собственно поэтому раньше программировали по другому, потому что так проще программировать без ошибок. Вот только мало кто умеет все эти сложности микросервисной архитектуры реализовывать без проблем. Громкие слова выучили, а нарушений data integrity сплошь и рядом. Обычно эти проблемы решаются тем, что когда устраиваются на работу стараются попасть проект который только начал разрабатываться, а когда проект доходит до прода все стремительно начинают искать новую работу. :)
Да тут вы подтвердили мои слова. А в случае продакшина исползуются облака кубернетись. Там то как вы мантируете? Сетевая файловая система? NFS? CephFS?
Да нет, есть же. Сделать то же самое, только без контейнеров, гораздо проще. :) Дебианподобные дистрибутивы и репозиторий от postgres для редхатоподобных поддерживает одновременную установку пакетов постгреса разных версий. Там достаточно просто установить пакет с новой версией и никакой возни с тем, что вы называете "нет ничего проще". :)
Холоп это военнопленный, наихудшая форма рабства на Руси. Потом так стали называть и обычных крестьян. А полным аналогом "мастэ" будет господин он же господарь. Это и было обозначение рабовладельца, которое потом перешло в обычное обращение. Собственно когда цари стали себя наименовать "господарь всея Руси" это означало что всё остальное население, включая дворян, это рабы по отношению к царю. При великих князьях такого разумеется не было.
Ну а если серьезно, почему я использовал "мастер" и "раб", потому что, понятно, английские термины, которые приняты много где, в том числе и Pacemaker, это master и slave. И если слово "мастер" по русским падежам нормально склоняется, то как "слейв" склоняется по падежам мне не понравилось.
Комментарии сильно уклонились от темы статьи. Если вы еще не поняли, то я поясню, статья была про то, как можно искать (и находить) недостатки Pacemaker. Вместо этого набежали адепты Patroni и с религиозным фанатизмом (по другому и не скажешь) стали доказывать, что Patroni самый лучший в мире. Словно я покушаюсь на ваши доходы. :)
Поэтому я предлагаю закончить совершенно неуместный здесь холивар и вернуться к теме статьи. Инструмент для тестирования Pacemaker я написал. Хороший или плохой он, можно обсуждать, то что его можно улучшать и совершенствовать (как инструмент, так и Pacemaker) это бесспорно.
Так что вместо того, чтобы сотрясать воздух эмоциональными высказываниями и давить "авторитетом", предлагаю более конструктивный путь. Форкните проект, замените ту часть, где развертывается Pacemaker на Patroni, покажите миру как все классно работает. Я за здоровую конкуренцию. Сложного там ничего нет, главные заморочки были с многооконным интерфейсом в tmux, само развертывание и тестирование достаточно очевидно. Не нравится bash? Мне он тоже не нравится. Перепишите на python или на что сочтете нужным.
Вы же понимаете, как сильно можно будет поднять бабла, если во время лекций можно будет не просто так сотрясать воздух или показывать видео, а в реальном времени показывать, что вот, происходят отказы и как система с ними борется. Или вот, система успешно преодолела 1000 отказов. (Кстати на Pacemaker я до этой цифры так и не дошел. Как уже сказал, есть чего совершенствовать. :) Для такого использования во время демонстраций, кстати, надо сохранить способность системы целиком работать на одном MacBook Pro.
Когда единственный аргумент, который может предоставить разработчик отказоустойчивой системы, вот такой, это вызывает еще больший скепсис. :)
Вы так говорите, словно я как будто бы говорю, что веб-разработчики второй сорт. :) И пытаетесь спорить со мной по тем с вашей стороны спорным моментам, которые вы же сами для меня и придумали. Нет. Если вам интересная моя действительная точка зрения, то веб-разработчики это параллельная ветвь эволюции, альтернативная цивилизация. Обычные программисты зародились где-то в середине прошлого века (если не считать Аду Байрон), перфокарты, релейные компьютеры и всё такое. Породили их инженеры, математики. Прошли свой эволюционный путь, создали свою цивилизацию, культуру, парадигмы программирования, понятия о добре и зле. Веб-разработчики появились гораздо позже, произошли они от того что веб-дизайнеры, которые были по сути гуманитарии, программировали что-то для своих нужд на php, perl и прочих языках с нестрогой типизацией, которых нормальные программисты избегали как черт ладана. Но не смотря на всю иронию и скепсис обращенный в их адрес веб-разработчики сумели доказать свою эволюционную приспособленность, главным образом тем, что они захватили и удерживают большУю часть рынка услуг и труда (а в России так и бОльшую). И заметно как тонкие клиенты повсеместно вытесняют толстые. Возникнув независимо веб-разработчики создали свою альтернативную цивилизацию, культуру, свои парадигмы. На нормальных программистов они похожи примерно так же, как головоногие на приматов. Но не смотря на всю иронию можно только уважительно относится к их способности отжимать рынок. :) Есть чему поучится, проанализировать почему так происходит.
Когда я вижу, что сисадмины опять суетятся по утру с красными глазами, я понимаю, что у них опять проблемы с Кубернетисом. :) Это был легкая ирония, а сейчас объясню свой сарказм по поводу СУБД внутри контейнеров. Если читать документацию к докеру, там буквально на первых страницах объясняются принципы использования контейнеров. Один из них, все данные связанные с логикой работы сервиса внутри контейнера должны храниться вне контейнера, либо на серверах баз данных, либо на внешних (по отношению к контейнеру) разделах, которые в него мантируются. А в случае облаков Кубернетис с его "отказоустойчивостью" и балансировкой нагрузки тут уже, наверное, речь идет сетевых файловых системах. Но не суть важно, PostgreSQL это база данных и по самим принципам создания сервисов в контейнерах она должна быть расположена вне контейнеров. :)
Хотя я признаю, что для таких целей как разработка и тестирование виртуалки и контейнеры действительно могут быть полезны. Этот проект тому подтверждение.
Пока ничего сказать не могу. Придется подождать когда в стенде появится PostgreSQL 12.
Гайд был написан для внутреннего использования, у нас на столько старых БД нету.
C pg_upgrade немало проблем, все они помечены "еще один камушек в сторону pg_upgrade".
В смысле? Проект в OpenSource.