Это надо очень постараться, чтобы изменился порядок сохраненных записей при изменении таймзоны, т.к. изменение таймзоны - это добавление константного смещения для всех записей (т.е. ко всем timestamp прибавится, допустим, 3 часа). От этого порядок записей измениться никак не может. Можно, наверное, конечно, сильно постараться - хранить, например, таймстемпы не как таймстемпы, а как какие-то строковые представления и тогда умудриться неумело добавлять время (например, при переходе с одной даты на другую)... но это надо быть очень забористым программистом (или архитектором БД), чтобы такое выдумать.
Интересно, а как может "поломаться" сортировка при отображении карточек, если поменять таймзону клиента? Ведь изменение таймзоны - это в общем случае просто добавление одинакового смещения для всех отметок времени, что на сортировку никак не влияет.
честно говоря не понял про какие хеши речь с помощью которых можно проверить выполнилась транзакция или нет.. да ещё и рассчитываемые на триггерах (триггерах базы? это ещё и схемы менять что ли?). также не понял что за база знаний. ..очень как-то всё сложно и искусственно, на мой взгляд, много допущений и много вопросов. но больше всего, если честно, так и непонятно для чего это когда есть проверенные достаточно эффективные механизмы.
а "практика и бизнес", они, как ни странно, разные бывают. бывает, что и микроскопами гвозди забивают, а потом радуются как эффективно это было сделано. ;)
ну.. в целом согласен, что каждый высказался, и другая сторона услышала достаточно, чтобы принять к сведению, задуматься или не принять к сведению и не задуматься :)
1. Когда я говорил про триггеры - я говорил по сути о пользовательских функциях, которые на уровне субд вешаются на те или иные события в таблицах (добавление, обновление, удаление записей). Такие штуки недоступные вашему прокси не то что на предмет их внутренней логики работы, но даже на предмет вообще их наличия. А коли так, то в общем случае прокси не может оценивать является ли тот или иной запрос на изменения идемпотентным или нет, т.е. можно его отправлять на все серверы или нет. самое интересно, что если вы даже каким-то образом определили, что запрос не идемпотентный, отправили его на один сервер, то потом у вас возникает проблема - а как же провести синхронизацию изменений?.. ведь добавление (или изменение) записи может изменять данные не только в одной таблице. Например, изменение суммы счета в таблице счетов может с помощью отработки триггеров обновлять информацию в таблице каких-нибудь итогов сделанную для аналитики.
Зеркалирование запросов на все серверы в общем случае (даже если всё там просто с запросами) не является "самым быстрым способом". Почему? Дело в том, что т.к. у вас используется механизм подтверждения выполнения запроса всеми серверами (как - вопрос десятый), то время выполнения запроса с точки зрения сервера приложений будет определяться временем выполнения запроса самым медленным сервером (это если ничего не упадет. если упадет - то всё вообще встанет). Почему будут быстрые и медленные серверы если они одинаковые? Ну, самый явный ответ такой. Т.к. в вашей системе запросы на чтение перераспределяются между разными серверами, то состояние памяти, кэшей, загрузки процессоров, буферов ввода/вывода и т.п. будет на серверах разное, и кому-то не нужно будет читать данные с дисков для выполнения запроса, а кому-то нужно (если очень просто). В стандартной схеме репликации (допустим синхронной) всё гораздо проще и быстрее. На мастере строится план выполнения запроса (у вас он будет строиться каждым сервером самостоятельно). Запрос выполняется, но транзакция не закрывается. При выполнении формируется WAL-файл, который передается на все серверы-реплики. Серверы реплики проигрывают этот файл (это не выполнение запроса, а уже гораздо более быстрые операции со страницами данных, индексов и т.п.). Если всё ок - то передается подтверждение о том, что транзакция выполнена. Мастер получив подтверждения закрывает транзакцию (делает у себя commit). Примерно так.
2. Чаще всего, пожалуй, основную нагрузку (в части системы ввода/вывода например) будут создавать запросы на чтение (просто в силу того что чаще всего их больше). Я с этим и не спорил :) Но это, тоже кстати, не всегда. Могут быть системы в которых это не так. Допустим, чисто гипотетически, какая-то система хранения сырых данных, поступающих с датчиков мониторинга, где сами сырые данные практически для доступа не используются. Но, ещё раз, балансировка/распределение запросов на чтение между всеми нодами кластера - это тоже достаточно стандартная процедура (и я вам тоже про это писал). :)
3. То, что у вас равномерно нагружаются все ноды, к сожалению, не говорит о том, что работают они эффективно, а просто говорит о том, что они выполняют одну и ту же работу.
Объясню в чем разница. Пусть каждая ваша нода может выполнять 10 операций в единицу времени. И пусть операция добавления одной записи занимает 6 операций, операция репликации занимает 4 операции (я уже писал, почему это быстрее простого выполнения запроса выше), а операция чтение - 2 операции.
Фишка в том, что в вашем случае каждая из нод потратит по 6 операций на добавление и у каждой останется по 4 операции на выполнение, допустим, 2 чтений. Ноды будут загружены равномерно.
В случае репликации мастер нода потратит те же 6 операций, и у неё останется 4 операции для 2х чтений, но остальные ноды потратят по 4 операции и у них останется по 6 операция для 3х чтений.. Ноды (в свете операция добавления записей), конечно по графику будут загружены неравномерно, но эта неравномерность будет говорить о том, что большинство нод могут сделать больше работы (например обработать больше запросов на чтение)
...такие вот простые рассуждения
P.S.: под "не идемпотентным" в данном случае понимается запрос, который при выполнении на разных серверах будет давать разный результат
Все 4 описанных вами сценария реализуются по достаточно стандартным схемам. "Катастрофоустойчивость" по сути отличается только размещением узлов кластер, а производительность обеспечивается, как минимум, распределение запросов на чтение для кластеров с одним мастером/лидером) или всех запросов для кластеров с несколькими мастер-узлами (я писал про это.. там где про Европу и Азию).
В статье совершенно не про мультимастера. Почему? Потому что никакого распределения нагрузки по записи не происходит. Функцию мастера пытаются переложить на какую-то оболочку, которая отправляет одни и те же(!) запросы на множество серверов с ожиданием подтверждения их выполнения. Сравните с тем, как делается стандартная синхронная репликация в постгре, и попробуйте ответить на вопрос зачем нужна эта оболочка и чем она лучше мастер-ноды в схеме стандартной репликации.
Мультимастер системы (в субд) - это не то, что Вы описываете, а системы которые имеют в кластере несколько узлов независимо принимающих все типы запросов (и на чтение и на изменение) и при этом обеспечивается целостность данных на уровне всего кластера (логику работы я вам тоже приводил). У вас же описана какая то система (даже не репликации), а синхронного выполнения запросов (т.е. выполнение запросов с подтверждением) на нескольких серверах. Это даже не вписывается в ни в кластер ms sql (с его always on) ни в кластер postgresql (с его потоковой репликацией) описанный в решении Data Cluster вашей же компании.
Вы описываете оболочку, которая операции изменения отдаёт сразу на все ноды (даже не ноды, а независимые серверы). В вашей схеме, если просто, сервер приложений отдаёт запрос (например, insert) на вашу оболочку, которая отправляет этот запрос на все серверы субд. Потом она неким образом проверяет (ожидает подтверждения), что везде всё выполнилось и считает, что всё ок, а если где-то не выполнилось, то откатывает изменения на всех серверах. Цитата:
Если тип запроса Изменение, то отправляет его на все сервера асинхронно. При этом к следующему запросу он не переходит, пока не дождется положительного ответа от всех серверов. Если произошла ошибка, то она транслируется в клиентское приложение и откатывается транзакция на всех серверах
Небольшое пояснение. Синхронная репликация не значит, что данные реплицируются последовательно на серверы. Это значит, что при шаге репликации ожидается подтверждение о том, что репликация завершилась успехом. А сами запросы отправляются на серверы с максимальной скоростью (это вы называете асинхронно).
По приведенной цитате сразу возникает куча вопросов, но самы "толстый" - это: т.е. если один из допустим 10 серверов не смог выполнить запрос (место на диске закончилось или сетевой порт умер), то вместо того чтобы исключить этот сервер как неработающий, предлагается просто парализовать работу всех других серверов.. Офигенное решение! Поставить 10 серверов, чтобы отказ одного остановил работу всей системы.
Про скорость работы такого решения можно даже особо не говорить: построение плана выполнения запроса - везде, дополнительные затраты на анализ и модификацию запросов.. Похоже, что всё, что у вас выполняется по плану - ограничено простейшими update, insert, delete и select. О хранимых функциях, тригерах, динамическом построении запросов речи здесь вообще не будет.
По части технической реализации (кроме общего упоминания общих терминов вроде 'прокси' или 'мастер') вы практически ничего не пишите (от слова "совсем"). Поэтому странно упрекать меня в отсутствии технических описаний. Особенно, с учётом того, что это не я статью писал, а вы, а в комментариях я даже более детально пишу о том, как происходит репликация в кластере постгре, а также о том какие программный средства используются обычно для построения отказоусточивых кластерных решений для постгре.
По поводу мультимастера я тоже написал выше (вы снова невнимательны).
Кстати, как организовывается у вас отказоустойчивость самой вашей оболочки (или того же Data Cluster) тоже ничего нет (технического описания).
Читал про ваш data cluster. По описанию за мульт в год предлагается что-то вроде бесплатного haproxy (в лучшем случае в комбинации с keepalived) при стандартно развёрнутом кластере postgresql или кластере mssql. При этом, вы уж извините, описание на сайте такое же технически корявое, как и статья. И никакой конкретики. Есть термины always on и потоковая репликация, которые относятся к стандартным механизмам построения кластером от ms и к репликации постгре (про это я вам писал, кстати), но именно про само решение практически ничего технического не сказано - общие слова. Смешали всё в кучу, описали стандартную схему построения кластер высокой доступности для двух субд и при этом, про само решение - что это и чем это отличается от чего-то стандартного так ничего и не сказали (с технической точки зрения).
По поводу медалек и реестров, - это бумажки, а с учётом выше сказанного их реальная ценность достаточно спорная, вы уж извините :)
По поводу "горизонтального масштабирования".. Вы серьёзно не понимаете что это такое или чисто шутите? Для примера ссылки не нужны. Кластер сам по себе это и есть штука, которая придумана для "горизонтально масштабирования" системы. Добавляете ноду, перераспределяете нагрузку (в данном случае добавляете ещё один сервер, который может обрабатывать запросы на чтение) и тем самым горизонтально масштабируете систему. ..я про это выше писал, но вы, видимо, это пропустили.
..на всякий случай:
Высокодоступность - это про то, что умирание одной из нод позволяет системе продолжать работу.
Плохо, что вы не утруждаете себя разбираться в технических вопросах ...может это из за скоростного чтения :). Возможно тогда вы бы поняли о чем на самом деле приведенная ссылка и зачем там разные технические описания.
На всякий случай приведу ещё одну ссылку, где тоже присутствуют технические описания и схемы про кластеры постгре и ms sql, но, скорее всего, для вас это тоже будет неинтересно и не убедительно :)
https://infostart.ru/1c/articles/1499932/
P. S. : когда техническая составляющая туманна - на первый план выступает хороший маркетинг ;)
Вы как-то путаетесь в терминах. Это кластер бывает отказоусточивым, а не нода. Думаю, что никакой "отчёт" вы никуда не "перенаправите", если у вас нода с этим "отчётом" перестала работать.
А по поводу временных таблиц в 1с.. Вы правы, я не специалист в тонкостях работы 1С и даже не могу назвать себя специалистом в кластерах, но.. Вы всё же невнимательно прочитали статью по ссылке. А она была именно про 1С (о чем я вам сказал). Почитайте там раздел: Использование резервного сервера PostgreSQL для механизма копий базы данных. Возможно в нем есть ответы на ваши вопросы. ;)
"Какой-то там кластер" - серьёзное утверждение для кластеров на ПО, используемых Red Hat, IBM Compose, Zalando и др..
Кстати, Mazars, тоже использовала patroni для организации кластер для 1с (порядка 200 баз, как они писали) .. по крайней мере в 2021ом.
P. S. : читайте более внимательно и возможно..... не потребуется городить огородов на ровном месте ;)
Вы видимо совсем не читали то, что я вам прислал и, похоже, вообще мало читали по вопросу построения кластер в, в том числе отказоустойчивых и, в том числе, для постгре.
Отказоустойчивый кластер - это общепринятое название кластера с высокой доступностью (примерно то что вы у себя обозначаете 24/7).
Горизонтальная масштабируемость это обычно то, ради чего вообще кластеры и делаются. В кластер постгре она достигается за счёт перераспределение запросов на чтение между нодами кластера. Это достаточно стандартная практика.
А то что вы написали - это выглядит как попытка изобрести велосипед. При этом не очень удачная. Т.к., например, в силу описанных вами механизмов борьбы за согласованность данных , ваша система сразу будет проигрывать стандартным решениям в высоконагруженных приложениях с большими объёмами запросов на запись или изменение данных.
Вы почитайте про то как данные синхронизируются в постгре, что такое потоковая синхронизация, асинхронная, синхронная, причём здесь wal-файлы, что такое patroni и как он связан с etcd или consul, посмотрите схемы построения кластеров постгре и т.д. Может окажется, что не нужно городить огороды на ровном месте.
Я прочитал, что запросы на чтение у вас распределяются неким образом. Но вы видимо невнимательно прочитали мой первый пост. В стандартных схема построения HA-кластера для постгре это давно реализуется достаточно стандартными решениями (я вам даже ссылку привёл. Там, вроде про это тоже говорится.. Причём на примере кластерах для 1С).
Я вам говорю о том, что то, что вы описываете, реализуется достаточно стандартными методами и по достаточно стандартным схемам. И в интернете масса примеров вплоть до пошаговый инструкций и объяснений как и почему.
Какой ещё "мастер-мастер". Вы пишите, что у вас транзакции (т.е. запросы на изменения) передаются сразу на все серверы. Здесь никакого "распределения" нет. Стандартная репликация в постгре работает практически так же, но быстрее - транзакция выполняется на мастере (формируется план выполнения и т.п.) а на реплики передаётся wal-файлы, который там проигрывается (асинхронно или синхронно). Всё распределение нагрузки в таких кластерах (как и у вас) - это только распределение нагрузки по чтению.
Мульти-мастер читал собирали на mysql - это когда разные запросы на изменения могут принимать разные ноды (например нода в Европе и нода в Азии) и потом делать синхронизацию в обе стороны.
Более того. В вашей схеме нужно ещё потрудиться, чтобы данные на всех нодах были консистентные (у вас же нет мастера явного который может выступать эталоном). Т.е. Вы всегда пытаетесь делать по сути синхронную репликация, что является медленным решением и оправдано не всегда.
Не понял, а чем относительно стандартная реализация построения кластер высокой доступности для постгре не устраивает? Postgresql, patroni, etcd, keepalived, haproxy, pgbouncer.. Стандартная потоковая репликация (асинхронная или синхронная), лидер (запросы на запись/чтение) и несколько реплик (запросы на чтение)
Вообще странно говорить о том, что если вопрос задан в чате, то на него не смотрят и не отвечают, а если то же самое задано при встречи 10 человек, то все бросятся на него отвечать, а те кому это вообще не нужно будут внимательно внимать ответу, переваривать ненужную информацию или вежливо сидеть в стороне.
Конечно, если в рабочем чате рассказывать про погоду, поход в кино и обсуждение книг, то наверное там будет "100500" сообщений которые занятой разработчик не будет читать (вместе с теми, что "по делу").
Это без вопросов. В данном случае даже лучше, наверное, сказать не "нужно", а "приходится". Думаю, что автор говорит как раз о трудностях, которые могут возникнуть и которые желательно сразу предусмотреть и избежать или минимизировать. Но это, конечно, не значит, что они возникнут обязательно и везде.
А если не поддерживает? В таких случаях (общие рассуждения), наверное, лучше задаваться вопросом не: "а если всё хорошо", а вопросом: "а если всё плохо". Т.е. это вопрос не максимизации выгоды при хорошем стечении обстоятельств, а минимизации потерь при плохом стечении обстоятельств. А так-то у нас и программы все без ошибок пишут. :)
Уникальность это в данном случае не самое главное. Если вин будет первичным ключе, то его изменение может потребовать каскадных изменений во всех связях, где он используется. Вот это проблема.
Допустим есть у вас таблица дополнительно, где хранится история тех.осмотров машин (каждая машина проходит несколько тех.осмотров). Если вин - первичный ключ, то его изменение в таблице машин (где он первичный ключ) потребует изменения соответствующих идентификаторов в таблице техобслуживаний.
Если разработка сервиса ZooBiZoo обходилась клиенту в 700 тысяч в месяц, то мне, если честно, всеравно на чем он был написан.. Я просто склоняю голову перед тем, кто сумел продать такую залепку за такие деньги... ...и это же не один месяц получается....
Похоже, что про зарабатывание денег начали говорить "бизнесмены от ИТ". Программист, наверное сопоставил бы ещё пару терминов. Есть ещё разбой, воровство, мошенничество. У них тоже смысл в зарабатывании денег. И некоторые это тоже называют "бизнесом".
Я к тому, что бизнес бизнесу, наверное, рознь. И если весь твой бизнес - это чисто зарабатывание денег (всеравно как, всеравно с каким результатом для других, всеравно какими способами), то как сказали выше, видимо, "х...вый" у тебя бизнес. Конечно, не для тебя, а для тех, кто под бизнесом (и программированием) понимает несколько другое, кроме как "зарабатывание денег".
А вообще автор статьи прав, по-моему, на все 100%. Слишком часто (и всё чаще) сталкиваешся с тем, о чем он говорит.
Как пример, больше года назад одна компания (где-то в сфере росатома) сделала программный продукт для гос сектора. Получила N миллионов (это бизнес). Только оказалось, что программный продукт не работает (новости не показывает, адреса не выбирает, события не загружает и т.д.). Почти год бились с этим. В итоге практически всё переписали с нуля своими силами. А компания тем временем заключила ещё контракт на то же самое на M миллионов. Вот такой вот "бизнес по определению". :)
Супер! Красавчик :)
Это надо очень постараться, чтобы изменился порядок сохраненных записей при изменении таймзоны, т.к. изменение таймзоны - это добавление константного смещения для всех записей (т.е. ко всем timestamp прибавится, допустим, 3 часа). От этого порядок записей измениться никак не может.
Можно, наверное, конечно, сильно постараться - хранить, например, таймстемпы не как таймстемпы, а как какие-то строковые представления и тогда умудриться неумело добавлять время (например, при переходе с одной даты на другую)... но это надо быть очень забористым программистом (или архитектором БД), чтобы такое выдумать.
Интересно, а как может "поломаться" сортировка при отображении карточек, если поменять таймзону клиента? Ведь изменение таймзоны - это в общем случае просто добавление одинакового смещения для всех отметок времени, что на сортировку никак не влияет.
честно говоря не понял про какие хеши речь с помощью которых можно проверить выполнилась транзакция или нет.. да ещё и рассчитываемые на триггерах (триггерах базы? это ещё и схемы менять что ли?). также не понял что за база знаний.
..очень как-то всё сложно и искусственно, на мой взгляд, много допущений и много вопросов. но больше всего, если честно, так и непонятно для чего это когда есть проверенные достаточно эффективные механизмы.
а "практика и бизнес", они, как ни странно, разные бывают. бывает, что и микроскопами гвозди забивают, а потом радуются как эффективно это было сделано. ;)
ну.. в целом согласен, что каждый высказался, и другая сторона услышала достаточно, чтобы принять к сведению, задуматься или не принять к сведению и не задуматься :)
в любом случае, успехов :)
1. Когда я говорил про триггеры - я говорил по сути о пользовательских функциях, которые на уровне субд вешаются на те или иные события в таблицах (добавление, обновление, удаление записей). Такие штуки недоступные вашему прокси не то что на предмет их внутренней логики работы, но даже на предмет вообще их наличия. А коли так, то в общем случае прокси не может оценивать является ли тот или иной запрос на изменения идемпотентным или нет, т.е. можно его отправлять на все серверы или нет.
самое интересно, что если вы даже каким-то образом определили, что запрос не идемпотентный, отправили его на один сервер, то потом у вас возникает проблема - а как же провести синхронизацию изменений?.. ведь добавление (или изменение) записи может изменять данные не только в одной таблице. Например, изменение суммы счета в таблице счетов может с помощью отработки триггеров обновлять информацию в таблице каких-нибудь итогов сделанную для аналитики.
Зеркалирование запросов на все серверы в общем случае (даже если всё там просто с запросами) не является "самым быстрым способом". Почему? Дело в том, что т.к. у вас используется механизм подтверждения выполнения запроса всеми серверами (как - вопрос десятый), то время выполнения запроса с точки зрения сервера приложений будет определяться временем выполнения запроса самым медленным сервером (это если ничего не упадет. если упадет - то всё вообще встанет). Почему будут быстрые и медленные серверы если они одинаковые? Ну, самый явный ответ такой. Т.к. в вашей системе запросы на чтение перераспределяются между разными серверами, то состояние памяти, кэшей, загрузки процессоров, буферов ввода/вывода и т.п. будет на серверах разное, и кому-то не нужно будет читать данные с дисков для выполнения запроса, а кому-то нужно (если очень просто).
В стандартной схеме репликации (допустим синхронной) всё гораздо проще и быстрее. На мастере строится план выполнения запроса (у вас он будет строиться каждым сервером самостоятельно). Запрос выполняется, но транзакция не закрывается. При выполнении формируется WAL-файл, который передается на все серверы-реплики. Серверы реплики проигрывают этот файл (это не выполнение запроса, а уже гораздо более быстрые операции со страницами данных, индексов и т.п.). Если всё ок - то передается подтверждение о том, что транзакция выполнена. Мастер получив подтверждения закрывает транзакцию (делает у себя commit). Примерно так.
2. Чаще всего, пожалуй, основную нагрузку (в части системы ввода/вывода например) будут создавать запросы на чтение (просто в силу того что чаще всего их больше). Я с этим и не спорил :)
Но это, тоже кстати, не всегда. Могут быть системы в которых это не так. Допустим, чисто гипотетически, какая-то система хранения сырых данных, поступающих с датчиков мониторинга, где сами сырые данные практически для доступа не используются.
Но, ещё раз, балансировка/распределение запросов на чтение между всеми нодами кластера - это тоже достаточно стандартная процедура (и я вам тоже про это писал). :)
3. То, что у вас равномерно нагружаются все ноды, к сожалению, не говорит о том, что работают они эффективно, а просто говорит о том, что они выполняют одну и ту же работу.
Объясню в чем разница. Пусть каждая ваша нода может выполнять 10 операций в единицу времени. И пусть операция добавления одной записи занимает 6 операций, операция репликации занимает 4 операции (я уже писал, почему это быстрее простого выполнения запроса выше), а операция чтение - 2 операции.
Фишка в том, что в вашем случае каждая из нод потратит по 6 операций на добавление и у каждой останется по 4 операции на выполнение, допустим, 2 чтений. Ноды будут загружены равномерно.
В случае репликации мастер нода потратит те же 6 операций, и у неё останется 4 операции для 2х чтений, но остальные ноды потратят по 4 операции и у них останется по 6 операция для 3х чтений.. Ноды (в свете операция добавления записей), конечно по графику будут загружены неравномерно, но эта неравномерность будет говорить о том, что большинство нод могут сделать больше работы (например обработать больше запросов на чтение)
...такие вот простые рассуждения
P.S.: под "не идемпотентным" в данном случае понимается запрос, который при выполнении на разных серверах будет давать разный результат
Все 4 описанных вами сценария реализуются по достаточно стандартным схемам. "Катастрофоустойчивость" по сути отличается только размещением узлов кластер, а производительность обеспечивается, как минимум, распределение запросов на чтение для кластеров с одним мастером/лидером) или всех запросов для кластеров с несколькими мастер-узлами (я писал про это.. там где про Европу и Азию).
В статье совершенно не про мультимастера. Почему? Потому что никакого распределения нагрузки по записи не происходит. Функцию мастера пытаются переложить на какую-то оболочку, которая отправляет одни и те же(!) запросы на множество серверов с ожиданием подтверждения их выполнения. Сравните с тем, как делается стандартная синхронная репликация в постгре, и попробуйте ответить на вопрос зачем нужна эта оболочка и чем она лучше мастер-ноды в схеме стандартной репликации.
Подробнее - смотри комментарий ниже.
Да, что значит "мастер-мастер"?..
Мультимастер системы (в субд) - это не то, что Вы описываете, а системы которые имеют в кластере несколько узлов независимо принимающих все типы запросов (и на чтение и на изменение) и при этом обеспечивается целостность данных на уровне всего кластера (логику работы я вам тоже приводил). У вас же описана какая то система (даже не репликации), а синхронного выполнения запросов (т.е. выполнение запросов с подтверждением) на нескольких серверах. Это даже не вписывается в ни в кластер ms sql (с его always on) ни в кластер postgresql (с его потоковой репликацией) описанный в решении Data Cluster вашей же компании.
Вы описываете оболочку, которая операции изменения отдаёт сразу на все ноды (даже не ноды, а независимые серверы). В вашей схеме, если просто, сервер приложений отдаёт запрос (например, insert) на вашу оболочку, которая отправляет этот запрос на все серверы субд. Потом она неким образом проверяет (ожидает подтверждения), что везде всё выполнилось и считает, что всё ок, а если где-то не выполнилось, то откатывает изменения на всех серверах. Цитата:
Небольшое пояснение. Синхронная репликация не значит, что данные реплицируются последовательно на серверы. Это значит, что при шаге репликации ожидается подтверждение о том, что репликация завершилась успехом. А сами запросы отправляются на серверы с максимальной скоростью (это вы называете асинхронно).
По приведенной цитате сразу возникает куча вопросов, но самы "толстый" - это: т.е. если один из допустим 10 серверов не смог выполнить запрос (место на диске закончилось или сетевой порт умер), то вместо того чтобы исключить этот сервер как неработающий, предлагается просто парализовать работу всех других серверов.. Офигенное решение! Поставить 10 серверов, чтобы отказ одного остановил работу всей системы.
Про скорость работы такого решения можно даже особо не говорить: построение плана выполнения запроса - везде, дополнительные затраты на анализ и модификацию запросов.. Похоже, что всё, что у вас выполняется по плану - ограничено простейшими update, insert, delete и select. О хранимых функциях, тригерах, динамическом построении запросов речи здесь вообще не будет.
По части технической реализации (кроме общего упоминания общих терминов вроде 'прокси' или 'мастер') вы практически ничего не пишите (от слова "совсем"). Поэтому странно упрекать меня в отсутствии технических описаний. Особенно, с учётом того, что это не я статью писал, а вы, а в комментариях я даже более детально пишу о том, как происходит репликация в кластере постгре, а также о том какие программный средства используются обычно для построения отказоусточивых кластерных решений для постгре.
По поводу мультимастера я тоже написал выше (вы снова невнимательны).
Кстати, как организовывается у вас отказоустойчивость самой вашей оболочки (или того же Data Cluster) тоже ничего нет (технического описания).
Читал про ваш data cluster. По описанию за мульт в год предлагается что-то вроде бесплатного haproxy (в лучшем случае в комбинации с keepalived) при стандартно развёрнутом кластере postgresql или кластере mssql. При этом, вы уж извините, описание на сайте такое же технически корявое, как и статья. И никакой конкретики. Есть термины always on и потоковая репликация, которые относятся к стандартным механизмам построения кластером от ms и к репликации постгре (про это я вам писал, кстати), но именно про само решение практически ничего технического не сказано - общие слова. Смешали всё в кучу, описали стандартную схему построения кластер высокой доступности для двух субд и при этом, про само решение - что это и чем это отличается от чего-то стандартного так ничего и не сказали (с технической точки зрения).
По поводу медалек и реестров, - это бумажки, а с учётом выше сказанного их реальная ценность достаточно спорная, вы уж извините :)
По поводу "горизонтального масштабирования".. Вы серьёзно не понимаете что это такое или чисто шутите? Для примера ссылки не нужны. Кластер сам по себе это и есть штука, которая придумана для "горизонтально масштабирования" системы. Добавляете ноду, перераспределяете нагрузку (в данном случае добавляете ещё один сервер, который может обрабатывать запросы на чтение) и тем самым горизонтально масштабируете систему. ..я про это выше писал, но вы, видимо, это пропустили.
..на всякий случай:
Высокодоступность - это про то, что умирание одной из нод позволяет системе продолжать работу.
Плохо, что вы не утруждаете себя разбираться в технических вопросах ...может это из за скоростного чтения :). Возможно тогда вы бы поняли о чем на самом деле приведенная ссылка и зачем там разные технические описания.
На всякий случай приведу ещё одну ссылку, где тоже присутствуют технические описания и схемы про кластеры постгре и ms sql, но, скорее всего, для вас это тоже будет неинтересно и не убедительно :)
https://infostart.ru/1c/articles/1499932/
P. S. : когда техническая составляющая туманна - на первый план выступает хороший маркетинг ;)
Какими "регалиями на тему репликации"? Максимальная "регалия" в такой теме (если вы не пишите свою субд) - это "я умею настраивать репликации" :)
Вы как-то путаетесь в терминах. Это кластер бывает отказоусточивым, а не нода. Думаю, что никакой "отчёт" вы никуда не "перенаправите", если у вас нода с этим "отчётом" перестала работать.
А по поводу временных таблиц в 1с.. Вы правы, я не специалист в тонкостях работы 1С и даже не могу назвать себя специалистом в кластерах, но.. Вы всё же невнимательно прочитали статью по ссылке. А она была именно про 1С (о чем я вам сказал). Почитайте там раздел: Использование резервного сервера PostgreSQL для механизма копий базы данных. Возможно в нем есть ответы на ваши вопросы. ;)
"Какой-то там кластер" - серьёзное утверждение для кластеров на ПО, используемых Red Hat, IBM Compose, Zalando и др..
Кстати, Mazars, тоже использовала patroni для организации кластер для 1с (порядка 200 баз, как они писали) .. по крайней мере в 2021ом.
P. S. : читайте более внимательно и возможно..... не потребуется городить огородов на ровном месте ;)
Вы видимо совсем не читали то, что я вам прислал и, похоже, вообще мало читали по вопросу построения кластер в, в том числе отказоустойчивых и, в том числе, для постгре.
Отказоустойчивый кластер - это общепринятое название кластера с высокой доступностью (примерно то что вы у себя обозначаете 24/7).
Горизонтальная масштабируемость это обычно то, ради чего вообще кластеры и делаются. В кластер постгре она достигается за счёт перераспределение запросов на чтение между нодами кластера. Это достаточно стандартная практика.
А то что вы написали - это выглядит как попытка изобрести велосипед. При этом не очень удачная. Т.к., например, в силу описанных вами механизмов борьбы за согласованность данных , ваша система сразу будет проигрывать стандартным решениям в высоконагруженных приложениях с большими объёмами запросов на запись или изменение данных.
Вы почитайте про то как данные синхронизируются в постгре, что такое потоковая синхронизация, асинхронная, синхронная, причём здесь wal-файлы, что такое patroni и как он связан с etcd или consul, посмотрите схемы построения кластеров постгре и т.д. Может окажется, что не нужно городить огороды на ровном месте.
Я прочитал, что запросы на чтение у вас распределяются неким образом. Но вы видимо невнимательно прочитали мой первый пост. В стандартных схема построения HA-кластера для постгре это давно реализуется достаточно стандартными решениями (я вам даже ссылку привёл. Там, вроде про это тоже говорится.. Причём на примере кластерах для 1С).
Я вам говорю о том, что то, что вы описываете, реализуется достаточно стандартными методами и по достаточно стандартным схемам. И в интернете масса примеров вплоть до пошаговый инструкций и объяснений как и почему.
Какой ещё "мастер-мастер". Вы пишите, что у вас транзакции (т.е. запросы на изменения) передаются сразу на все серверы. Здесь никакого "распределения" нет. Стандартная репликация в постгре работает практически так же, но быстрее - транзакция выполняется на мастере (формируется план выполнения и т.п.) а на реплики передаётся wal-файлы, который там проигрывается (асинхронно или синхронно). Всё распределение нагрузки в таких кластерах (как и у вас) - это только распределение нагрузки по чтению.
Мульти-мастер читал собирали на mysql - это когда разные запросы на изменения могут принимать разные ноды (например нода в Европе и нода в Азии) и потом делать синхронизацию в обе стороны.
Более того. В вашей схеме нужно ещё потрудиться, чтобы данные на всех нодах были консистентные (у вас же нет мастера явного который может выступать эталоном). Т.е. Вы всегда пытаетесь делать по сути синхронную репликация, что является медленным решением и оправдано не всегда.
Не понял, а чем относительно стандартная реализация построения кластер высокой доступности для постгре не устраивает? Postgresql, patroni, etcd, keepalived, haproxy, pgbouncer.. Стандартная потоковая репликация (асинхронная или синхронная), лидер (запросы на запись/чтение) и несколько реплик (запросы на чтение)
Как один из вариантов:
https://its.1c.ru/db/metod8dev/content/5971/hdoc
Вообще странно говорить о том, что если вопрос задан в чате, то на него не смотрят и не отвечают, а если то же самое задано при встречи 10 человек, то все бросятся на него отвечать, а те кому это вообще не нужно будут внимательно внимать ответу, переваривать ненужную информацию или вежливо сидеть в стороне.
Конечно, если в рабочем чате рассказывать про погоду, поход в кино и обсуждение книг, то наверное там будет "100500" сообщений которые занятой разработчик не будет читать (вместе с теми, что "по делу").
Чисто моё видение вопроса.
Это без вопросов. В данном случае даже лучше, наверное, сказать не "нужно", а "приходится".
Думаю, что автор говорит как раз о трудностях, которые могут возникнуть и которые желательно сразу предусмотреть и избежать или минимизировать.
Но это, конечно, не значит, что они возникнут обязательно и везде.
А если не поддерживает?
В таких случаях (общие рассуждения), наверное, лучше задаваться вопросом не: "а если всё хорошо", а вопросом: "а если всё плохо".
Т.е. это вопрос не максимизации выгоды при хорошем стечении обстоятельств, а минимизации потерь при плохом стечении обстоятельств. А так-то у нас и программы все без ошибок пишут. :)
Уникальность это в данном случае не самое главное. Если вин будет первичным ключе, то его изменение может потребовать каскадных изменений во всех связях, где он используется. Вот это проблема.
Допустим есть у вас таблица дополнительно, где хранится история тех.осмотров машин (каждая машина проходит несколько тех.осмотров). Если вин - первичный ключ, то его изменение в таблице машин (где он первичный ключ) потребует изменения соответствующих идентификаторов в таблице техобслуживаний.
Если разработка сервиса ZooBiZoo обходилась клиенту в 700 тысяч в месяц, то мне, если честно, всеравно на чем он был написан.. Я просто склоняю голову перед тем, кто сумел продать такую залепку за такие деньги... ...и это же не один месяц получается....
Похоже, что про зарабатывание денег начали говорить "бизнесмены от ИТ". Программист, наверное сопоставил бы ещё пару терминов. Есть ещё разбой, воровство, мошенничество. У них тоже смысл в зарабатывании денег. И некоторые это тоже называют "бизнесом".
Я к тому, что бизнес бизнесу, наверное, рознь. И если весь твой бизнес - это чисто зарабатывание денег (всеравно как, всеравно с каким результатом для других, всеравно какими способами), то как сказали выше, видимо, "х...вый" у тебя бизнес. Конечно, не для тебя, а для тех, кто под бизнесом (и программированием) понимает несколько другое, кроме как "зарабатывание денег".
А вообще автор статьи прав, по-моему, на все 100%. Слишком часто (и всё чаще) сталкиваешся с тем, о чем он говорит.
Как пример, больше года назад одна компания (где-то в сфере росатома) сделала программный продукт для гос сектора. Получила N миллионов (это бизнес). Только оказалось, что программный продукт не работает (новости не показывает, адреса не выбирает, события не загружает и т.д.). Почти год бились с этим. В итоге практически всё переписали с нуля своими силами. А компания тем временем заключила ещё контракт на то же самое на M миллионов. Вот такой вот "бизнес по определению". :)