История изменений
Исправление byko3y, (текущая версия) :
Иди проспись. BDR это асинхронный мультимастер
Проблема заключается в том, что этот «асинхронный мультимастер» по целостности данных не отличается от «синхронного» Galera:
https://aphyr.com/posts/327-jepsen-mariadb-galera-cluster
Фактическое же внесение изменений происходит асинхронно, и при попытке запросить инфу в режиме Snapshot с нескольких узлов ты получишь нецелостные данные, даже несмотря на то, что к каждому узлу данные доходят в правильном порядке — просто, они приходят с разной задержкой.
Какая разница тогда вообще? Собственно, сами разрабы галеры эту разницу и продают — она в том, что галера из коробки самостоятельно выходит из отвала узла. В основном. Если ты будешь кидать все записи на один узел BDR, то ты получишь аналогичную по производительности и надежности систему. Аналогичную по надежности — потому что Galera точно так же пролюбит некоторое количество последних закоммиченных, но не сохраненных на постоянный носитель данных. И еще у галеры хорого продается хитрый костыль, который прикрывает факт нарушения целостности, подтормаживая быстрые узлы, чтобы за ними поспели медленные. Что не отменяет того факта, что никаких строгих гарантий целостности Galera не дает.
Чтобы исправить проблему побитого снимка, клиент должен предварительно запросить со всех узлов номер последней транзакции, выбрать ту версию, которая доступна на нужном числе узлов, и делать запрос с изоляцией Snapshot по конкретной версии данных, чего, насколько мне известно, обычный MySQL делать не умеет. Да, есть поддержка темпоральных данных, но с этими штуками, опять-таки, нужно явно руками работать, и это значительно снизит производительность, потому что понадобится несколько запрос-ответов для инициации снимка. Я вот не помню, есть ли вообще какая-то распредленная СУБД, которая прям из коробки поддерживает целостность снимков — когда-то читал, но названий не вспомню.
Естественно, и Galera, и BDR свой подход выбрали потому, что жесткое поддержание ACID гарантий загоняют производительность кластера на днище, и, самое главное, угрожают фактору доступности, ради которого мультимастер и делался, поскольку работа люто тупящего кластера мало чем отличается от полного отказа. В конечном итоге, если у тебя есть много пишущий клиент, которому важно видеть актуальные и целостные данные, то единственный практически приемлимый способ это сделать для общего случая — это писать и читать этим клиентом в один-два узла, которые станут эталонными для кластера. Именно поэтому, например, в PostgreSQL из коробки есть поддержка синхронного двухмастера.
Исправление byko3y, :
Иди проспись. BDR это асинхронный мультимастер
Проблема заключается в том, что этот «асинхронный мультимастер» по целостности данных не отличается от «синхронного» Galera:
https://aphyr.com/posts/327-jepsen-mariadb-galera-cluster
Фактическое же внесение изменений происходит асинхронно, и при попытке запросить инфу в режиме Snapshot с нескольких узлов ты получишь нецелостные данные, даже несмотря на то, что к каждому узлу данные доходят в правильном порядке — просто, они приходят с разной задержкой.
Какая тогда разница тогда вообще? Собственно, сами разрабы галеры эту разницу и продают — она в том, что галера из коробки самостоятельно выходит из отвала узла. В основном. Если ты будешь кидать все записи на один узел BDR, то ты получишь аналогичную по производительности и надежности систему. Аналогичную по надежности — потому что Galera точно так же пролюбит некоторое количество последних закоммиченных, но не сохраненных на постоянный носитель данных. И еще у галеры хорого продается хитрый костыль, который прикрывает факт нарушения целостности, подтормаживая быстрые узлы, чтобы за ними поспели медленные. Что не отменяет того факта, что никаких строгих гарантий целостности Galera не дает.
Чтобы исправить проблему побитого снимка, клиент должен предварительно запросить со всех узлов номер последней транзакции, выбрать ту версию, которая доступна на нужном числе узлов, и делать запрос с изоляцией Snapshot по конкретной версии данных, чего, насколько мне известно, обычный MySQL делать не умеет. Да, есть поддержка темпоральных данных, но с этими штуками, опять-таки, нужно явно руками работать, и это значительно снизит производительность, потому что понадобится несколько запрос-ответов для инициации снимка. Я вот не помню, есть ли вообще какая-то распредленная СУБД, которая прям из коробки поддерживает целостность снимков — когда-то читал, но названий не вспомню.
Естественно, и Galera, и BDR свой подход выбрали потому, что жесткое поддержание ACID гарантий загоняют производительность кластера на днище, и, самое главное, угрожают фактору доступности, ради которого мультимастер и делался, поскольку работа люто тупящего кластера мало чем отличается от полного отказа. В конечном итоге, если у тебя есть много пишущий клиент, которому важно видеть актуальные и целостные данные, то единственный практически приемлимый способ это сделать для общего случая — это писать и читать этим клиентом в один-два узла, которые станут эталонными для кластера. Именно поэтому, например, в PostgreSQL из коробки есть поддержка синхронного двухмастера.
Исправление byko3y, :
Иди проспись. BDR это асинхронный мультимастер
Проблема заключается в том, что этот «асинхронный мультимастер» по целостности данных не отличается от «синхронного» Galera:
https://aphyr.com/posts/327-jepsen-mariadb-galera-cluster
Фактическое же внесение изменений происходит асинхронно, и при попытке запросить инфу в режиме Snapshot с нескольких узлов ты получишь нецелостные данные, даже несмотря на то, что к каждому узлу данные доходят в правильном порядке — просто, они приходят с разной задержкой.
Какая тогда разница тогда вообще? Собственно, сами разрабы галеры эту разницу и продают — она в том, что галера из коробки самостоятельно выходит из отвала узла. В основном. Если ты будешь кидать все записи на один узел BDR, то ты получишь аналогичную по производительности и надежности систему. Аналогичную по недежности — потому что Galera точно так же пролюбит некоторое количество последних закоммиченных, но не сохраненных на постоянный носитель данных. И еще факт нарушения целостности прикрыт хитрым костылем, который подтормаживает быстрые узлы, чтобы за ними поспели медленные. Что не отменяет того факта, что никаких строгих гарантий там нет.
Чтобы исправить проблему побитого снимка, клиент должен предварительно запросить со всех узлов номер последней транзакции, выбрать ту транзакцию, которая доступна на нужном числе узлов, и делать запрос с изоляцией Snapshot по конкретной версии данных, чего, насколько мне известно, обычный MySQL делать не умеет. Да, есть поддержка темпоральных данных, но с этими штуками, опять таки, нужно явно самому работать, и это значительно снизит производительность, потому что понадобится несколько запрос-ответов для инициации снимка. Я вот не помню, есть ли вообще какая-то распредленная СУБД, которая прям из коробки поддерживает целостность снимков — когда-то читал, но названий не вспомню.
Естественно, и Galera, и BDR свой подход выбрали потому, что жесткое поддержание ACID гарантий загоняют производительность кластера на днище, и, самое главное, угрожают фактору доступности, ради которого мультимастер и делался. В конечном итоге, если у тебя есть много пишущий клиент, которому важно видеть актуальные и целостные данные. то практически приемлимый единственный способ это сделать для общего случая — это писать и читать этим клиентом в один-два узла, которые станут эталонными для кластера. Именно поэтому, например, в PostgreSQL из коробки есть поддержка синхронного двухмастера.
Исходная версия byko3y, :
Иди проспись. BDR это асинхронный мультимастер
Проблема заключается в том, что этот «асинхронный мультимастер» по целостности данных не отличается от «синхронного» Galera:
https://aphyr.com/posts/327-jepsen-mariadb-galera-cluster Фактическое же внесение изменений происходит асинхронно, и при попытке запросить инфу в режиме Snapshot с нескольких узлов ты получишь нецелостные данные, даже несмотря на то, что к каждому узлу данные доходят в правильном порядке — просто, они приходят с разной задержкой.
Какая тогда разница тогда вообще? Собственно, сами разрабы галеры эту разницу и продают — она в том, что галера из коробки самостоятельно выходит из отвала узла. В основном. Если ты будешь кидать все записи на один узел BDR, то ты получишь аналогичную по производительности и надежности систему. Аналогичную по недежности — потому что Galera точно так же пролюбит некоторое количество последних закоммиченных, но не сохраненных на постоянный носитель данных. И еще факт нарушения целостности прикрыт хитрым костылем, который подтормаживает быстрые узлы, чтобы за ними поспели медленные. Что не отменяет того факта, что никаких строгих гарантий там нет.
Чтобы исправить проблему побитого снимка, клиент должен предварительно запросить со всех узлов номер последней транзакции, выбрать ту транзакцию, которая доступна на нужном числе узлов, и делать запрос с изоляцией Snapshot по конкретной версии данных, чего, насколько мне известно, обычный MySQL делать не умеет. Да, есть поддержка темпоральных данных, но с этими штуками, опять таки, нужно явно самому работать, и это значительно снизит производительность, потому что понадобится несколько запрос-ответов для инициации снимка. Я вот не помню, есть ли вообще какая-то распредленная СУБД, которая прям из коробки поддерживает целостность снимков — когда-то читал, но названий не вспомню.
Естественно, и Galera, и BDR свой подход выбрали потому, что жесткое поддержание ACID гарантий загоняют производительность кластера на днище, и, самое главное, угрожают фактору доступности, ради которого мультимастер и делался. В конечном итоге, если у тебя есть много пишущий клиент, которому важно видеть актуальные и целостные данные. то практически приемлимый единственный способ это сделать для общего случая — это писать и читать этим клиентом в один-два узла, которые станут эталонными для кластера. Именно поэтому, например, в PostgreSQL из коробки есть поддержка синхронного двухмастера.