Comments 71
Каковы потери производительности, которые уходят на согласование запроса со всеми мастерами(режим-то синхронный)? Желательно в процентах и в секундах.
Соединены ли у Вас мастера в рамках ЛВС или через Интернет?
Соединены ли у Вас мастера в рамках ЛВС или через Интернет?
Кластер через интернет — очень плохая идея, не смотря на то что можно меня gmcast.segment=, проблемы будут. Этого делать не стоит. Разве что у Вас нет своей собственной оптики между ДЦ.
Потери производительности безусловно есть, но в секундах они не измеряются точно, это мс. В процентах — не представляю как это вывести. Просто, считайте что сеть должна быть железобетонная и сервера одинаковые или близкие по конфигурации дисков и процессора, тогда потери будут минимальные.
Потери производительности безусловно есть, но в секундах они не измеряются точно, это мс. В процентах — не представляю как это вывести. Просто, считайте что сеть должна быть железобетонная и сервера одинаковые или близкие по конфигурации дисков и процессора, тогда потери будут минимальные.
А если очень хочется? Между разными ДЦ в разных странах. Нагрузка небольшая, каналы относительно стабильны и как правило плавают в диапазоне от 200 до 800 мегабит на коннект. Хочется мультимастер для биллинга и подобных штук.
Каких стоит ожидать проблем?
Каких стоит ожидать проблем?
По моим изысканиям всё упирается в RTT. Т.к. на каждый запрос(или коммит, точно не скажу) происходит согласование со всеми остальными мастерами, и когда они дадут согласие, тогда только сервер получивший запрос начнёт его выполнять. Посему маленький запрос на INSERT может вместо пары микросекунд выполняться до 200милисекунд из-за того что согласование произошло между серверами стоящими в России и Америке, например.
А ещё всё это становится более шатким, если Вы хотите как я иметь 5,6,7… мастеров.
А ещё всё это становится более шатким, если Вы хотите как я иметь 5,6,7… мастеров.
Нужно держать разные участки кластера в разных gmcast.segment, тогда что то еще получится.
Подробнее стоит почитать о gmcast.segment в документации по galera 3
Подробнее стоит почитать о gmcast.segment в документации по galera 3
innodb_file_per_table = 1
это разве хороший выбор в плане производительности на больших базах?
При репликации подобной схемой, автоинкримент на мастерах не затрагивается auto_increment_increment?
Автоинкремент вычисляется автоматически, он равен числу членов кворума. Т.е. количество нод СУБД и арбиттраторов.
innodb_file_per_table=1 нужен как минимум, для нормальной работы xtrabackup.
innodb_file_per_table=1 нужен как минимум, для нормальной работы xtrabackup.
Т.е. я правильно понимаю, что автоинкримент сквозной будет между мастерами, без пропусков? Не совсем понял механизм какой будет назначения primary key если я на двух серверах с потеряной связностью вставлю 100 записей в таблицу.
не будет коммита, если не будет коммита на всех нодах кворума. Так что ничего не сможет вставится при потере связанности. Нода без кворума переходит в точно для чтения или вообще закрывается.
насколько я знаю, это не так
по крайней мере было не так, когда я присматривадся galera
нет никакого синхронного коммита, каждый writeset проходит некую сертификацию, проверку на отсутствие конфликтов, и если она пройдена, транзакция считается закоммиченной на всех нодах, что будет по факту на каждой из нод — как повезет
что-то поменялось с тех пор?
по крайней мере было не так, когда я присматривадся galera
нет никакого синхронного коммита, каждый writeset проходит некую сертификацию, проверку на отсутствие конфликтов, и если она пройдена, транзакция считается закоммиченной на всех нодах, что будет по факту на каждой из нод — как повезет
что-то поменялось с тех пор?
А разве query_cache не рекомендуют отключать по той причине, что данные и так кешируются в буферном пуле innodb?
Нет его отключают совершенно по другой причине. Его не внедряли ранее, так как очень трудно согласовать кеш между всеми нодами и на первых порах это приводило к дедлоку по причине кеша. Те на одной ноде поменялась запись и значит кеш должен сбросится на всех. А допустим где то сервер под нагрузкой и кеш не сбрасывается и в итоге все ноды ждут сброса кеша на одной из нод. В итоге они напряглись и починили это. Теперь работает как часы, главное выполнять рекомендации.
innodb
innodb
Как я понимаю, главная проблема как раз в том что он однопоточный, такая себе критическая секция. Изначально создавался более похоже на хак чтобы ускорить работу не слишком быстрых на то время подсистем хранения. При вытеснении из кеша он лочится целиком, потому для систем с частыми вставками/обновлениями скорость выборок может существенно падать и создаваться затыки.
Вроде «раньше» советовали его вырубать по той причине, что однопоточный он. И вся мощь расшибалась лбом об мьютексы…
Но вроде в случае мастер-мастер это может быть не правдой, только как проверить?
Но вроде в случае мастер-мастер это может быть не правдой, только как проверить?
опытным путем, так как это почти не документированная фича сейчас.
Не, там в другом проблема. То есть в мьютексах, конечно. В момент когда нужно его очистить, в случае, если содержимое таблиц, к которым обращаются хранящиеся в нём запросы, поменялось, он держит глобальный мьютекс и все остальные запросы стоят. Такое особенно заметно при высокой нагрузке и большом размере query cache. А пока он себя обновить не решил — всё многопоточно. Случай мастер-мастера здесь роли не играет. Его фиксили, но недофиксили: там с архитектурой какие-то проблемы. Поэтому лучше просто держать маленьким: 256 MB всяко быстрее обновится, чем 4G.
А зачем согласовывать (или синхронизировать) кеш? Как это влияет на работу кластера и целостность данных?
Возможен ведь вариант при котором с одной ноды будут читаться данные из одной таблицы, а на другой ноде будет чтение из других таблиц или например будет вестись только запись без чтения или чтения будет гораздо меньше.
И все же, зачем query_cache если бд в innodb?
Ну и для примера, допустим размер бд > 50 Гб, при этом активные данные составляют порядка 10%, при этом:
600 r/s — selects,
50 r/s — updates,
20 r/s — inserts,
20 r/s — delete.
Как здесь быть с query_cache и как лучше в этом случае кешировать активные данные?
Возможен ведь вариант при котором с одной ноды будут читаться данные из одной таблицы, а на другой ноде будет чтение из других таблиц или например будет вестись только запись без чтения или чтения будет гораздо меньше.
И все же, зачем query_cache если бд в innodb?
Ну и для примера, допустим размер бд > 50 Гб, при этом активные данные составляют порядка 10%, при этом:
600 r/s — selects,
50 r/s — updates,
20 r/s — inserts,
20 r/s — delete.
Как здесь быть с query_cache и как лучше в этом случае кешировать активные данные?
Если не согласовать кеш то прочитав данные из другой ноды ты получишь уже не актуальные на данный момент.
Возможен любой вариант, это полноценный синхронный мульти-мастер. Во все ноды можно писать и читать одновременно.
в query_cache хранятся хеши запросов и ответы на них, в innodb копии страниц данных, с диска.
Те в одном случае результат в другом — исходные данные.
innodb должен быть как можно больше, так что бы вместить данные базы и не ходить за ними на диск.
query_cache должен быть минимально необходимым, до 512МБ максимум.
Возможен любой вариант, это полноценный синхронный мульти-мастер. Во все ноды можно писать и читать одновременно.
в query_cache хранятся хеши запросов и ответы на них, в innodb копии страниц данных, с диска.
Те в одном случае результат в другом — исходные данные.
innodb должен быть как можно больше, так что бы вместить данные базы и не ходить за ними на диск.
query_cache должен быть минимально необходимым, до 512МБ максимум.
А можно позанудствовать чуть-чуть?
У Оракла нет имплементации Galera — это совершенно независимый от него продукт.
Federated была разработана ещё в MySQL AB и, к сожалению, до сих пор официально поддерживается. К сожалению, потому что если вы пойдёте на bugs.mysql.com и сравните как быстро устраняются баги, например, репликации и Federated — будет понятно что я имею в виду =)
> Стоит добавить важный с точки зрения производительности параметр skip-innodb_doublewrite
Он ещё самый важный с точки зрения сохранности данных
У Оракла нет имплементации Galera — это совершенно независимый от него продукт.
Federated была разработана ещё в MySQL AB и, к сожалению, до сих пор официально поддерживается. К сожалению, потому что если вы пойдёте на bugs.mysql.com и сравните как быстро устраняются баги, например, репликации и Federated — будет понятно что я имею в виду =)
> Стоит добавить важный с точки зрения производительности параметр skip-innodb_doublewrite
Он ещё самый важный с точки зрения сохранности данных
сохранность данных на диске конкретоной ноды, это не очень важный фактор. состояние будет передано при sst. а вот для ускорения работы кластера в целом, нужно минимизировать работу субд с диском до минимально необходимого
Действительно интересно, MariaDB берет у Percona ее xtradb движек, а Percona берет у MariaDB — galera-у.
Так в итоге galera ok? Просто сейчас стоит задача по кластеру, раньше работал только с percona так как galera была еще beta.
Еще тут в голове выросла такая схема, если можно покретекуйте.
два роутера с keepalived, 4 ip адреса. Два из них между машинами могут мигрировать в случаи отказа.
Там же HAProxy, доступ к нему по DNS-RR.
HAPRoxy уже к web,mysql итд.
Кстати пробовали ли IPVS вместо HAProxy?
Еще тут в голове выросла такая схема, если можно покретекуйте.
два роутера с keepalived, 4 ip адреса. Два из них между машинами могут мигрировать в случаи отказа.
Там же HAProxy, доступ к нему по DNS-RR.
HAPRoxy уже к web,mysql итд.
Кстати пробовали ли IPVS вместо HAProxy?
лучше maxscale
но можно и haproxy.
но можно и haproxy.
Про maxscale не слышал, буду читать, спс. HAProxy просто уже знаком.
И да, Maria DB Galera — торт.
Документация: cloud.sycraft.info/index.php/s/ff1d36ddb40239262f276d2cd0478196
Описание: www.opennet.ru/opennews/art.shtml?num=41475
Документация: cloud.sycraft.info/index.php/s/ff1d36ddb40239262f276d2cd0478196
Описание: www.opennet.ru/opennews/art.shtml?num=41475
Так Galera же Codership Oy, почему Maria?
Спасибо за статью, очень интересный материал.
А насколько проблемно восстановление консистентности данных на всех узлах при выпадении одной из нод (скажем некий внеплановый ребут)? Каким образом осуществляется балансировка нагрузки в мульти мастер инстансах?
А насколько проблемно восстановление консистентности данных на всех узлах при выпадении одной из нод (скажем некий внеплановый ребут)? Каким образом осуществляется балансировка нагрузки в мульти мастер инстансах?
не сложно. Все происходит автоматически при запуске выпавшей ноды. Иногда нужно удалить все ее локальные данные и перезагрузить еще раз.
Различают 2 варианта передачи состояний. Полное и инкрементальное. При повреждении локальных данных или первом старте, будет происходить полный SST.
По балансировке — HAProxy или MaxScale. По первому, ссылка на статью в начале текста.
Различают 2 варианта передачи состояний. Полное и инкрементальное. При повреждении локальных данных или первом старте, будет происходить полный SST.
По балансировке — HAProxy или MaxScale. По первому, ссылка на статью в начале текста.
А можно подробнее про восстановление? Использую в продакшене два percona server в master-master репликации и любая перезагрузка одной из нод ведет к неизбежному геморою при восстановлении.
Касательно HAProxy — при алгоритме с последовательным распределением запросов на ноды рано или поздно sql репликация может перестать успевать за балансировщиком и появляются duplicate entry. Как вы этого избегаете?
Использую в связке с zabbix, поэтому особенно интересно :)
Касательно HAProxy — при алгоритме с последовательным распределением запросов на ноды рано или поздно sql репликация может перестать успевать за балансировщиком и появляются duplicate entry. Как вы этого избегаете?
Использую в связке с zabbix, поэтому особенно интересно :)
Ну класика же! Попробуйте использовать 3 ноды для кворума, при двух непонятно кто живой и кто прав.
Правда когда я использовал 3 ноды, возникали вопросы с записью. См ниже.
Правда когда я использовал 3 ноды, возникали вопросы с записью. См ниже.
никакого гемороя не будет. Важно понимать что, 2 ноды это мало. нужно как минимум 2 и абраттратор. А лучше 3 или 4.
Записывать нужно в один сервер или по крайней мере, что бы набор баз и таблиц в которую ведется запись была разной.
MaxScale умеет отправлять запись в один набор нод а чтение в другой. Причем на уровне запросов а не соединений.
Записывать нужно в один сервер или по крайней мере, что бы набор баз и таблиц в которую ведется запись была разной.
MaxScale умеет отправлять запись в один набор нод а чтение в другой. Причем на уровне запросов а не соединений.
Круто, спасибо.
Тогда если не затруднит, ещё пара вопросов:
1. Умеет ли maxscale работу с двумя нодами (как в моем случае)?
2. Есть ли рецепты по максимально безопасному и бастрому переезду с multi master схемы на кластер? И насколько мощным должен быть арбитратор?
А то потихоньку подходим к необходимости масштабироваться:
Тогда если не затруднит, ещё пара вопросов:
1. Умеет ли maxscale работу с двумя нодами (как в моем случае)?
2. Есть ли рецепты по максимально безопасному и бастрому переезду с multi master схемы на кластер? И насколько мощным должен быть арбитратор?
А то потихоньку подходим к необходимости масштабироваться:
Арбитратор это минимально мощный сервер.
что у вас за мульти-мастер?
что у вас за мульти-мастер?
2 инстанса percona server 5.6 с настроенной master-master репликацией расположенные на виртуалках с 8ядрами и 16гб оперативки + ucarp (т.е. по сути запись и чтение ведется только с одной ноды, вторая для горячего переключения в случае крэша).
я не совсем понимаю как мастер-мастер? перекресная репликация?
Да, классическая перекрестная репликация.
ой. это жесть)
просто удаляешь оба инстанса и ставишь галеру. плюс арбиттратор.
ну и mysql_upgrade --force
просто удаляешь оба инстанса и ставишь галеру. плюс арбиттратор.
ну и mysql_upgrade --force
А лучше 3 или 4не стоит… Лучше, это когда число голосов (ноды+арбитраторы) нечётное, иначе splitbrain более вероятен. Хотя это зависит от конкретной схемы включения, тем не менее нечётное число всегда предпочтительней.
Почему? откуда такие рекомендации, где почитать?.. Рекомендация лишь одна — нод должно быть более 2. А дальше без ограничений.
Что значит где почитать? Что по Вашему такое splitbrain и почему он происходит?
Попробую найти где-нить строки хоть в чей-нибудь документации… Где-то явно оно есть.
Тут указано про минимум 3 сервера, но они явно упустили момент с чётным числом узлов.
Попробую найти где-нить строки хоть в чей-нибудь документации… Где-то явно оно есть.
Тут указано про минимум 3 сервера, но они явно упустили момент с чётным числом узлов.
splitbrain возможен когда ноды теряют согласование транзакций, так как они не знаю какая имеет верное состояние в данных момент. Это возможно, лишь когда нод 2. Все что выше, за счет других нод или арбитратторов, это кворум и splitbrain не может быть. Хоть четное их чесло, хоть нет. Речь ведь о Galera?
Речь о любом кластерном решении и Galera не исключение. Если у Вас будет кластер из 4-х нод, то в качестве необходимого для кворума, сколько нод Вы укажите? А теперь предположим что кластер развалился пополам. Если в качестве кворума было указано:
2 ноды — то каждая половина решит что она главная и будет существовать независимо. Вот и коллизия данных.
3 ноды — кластер просто перестанет существовать, т.к. каждая половина решит что её мало.
Вот у percona есть про это, нашёл.
2 ноды — то каждая половина решит что она главная и будет существовать независимо. Вот и коллизия данных.
3 ноды — кластер просто перестанет существовать, т.к. каждая половина решит что её мало.
Вот у percona есть про это, нашёл.
я не буду указывать число нод в кворуме. Он будет выбирать это самостоятельно. Почему кластер должен развалится пополам? Если будет 4 ноды и они развалятся пополам, то будет 2 ноды по 2. Как вы сами и сказали, оба этих кластера не будут жизнеспособными.
Я бы еще согласился если бы нод было 5,6 или более.
Я бы еще согласился если бы нод было 5,6 или более.
Если число голосующих узлов будет нечётным, то не будет ситуации когда кластер развалится на две ЛЮБЫЕ части и при этом перестанет функционировать. И нету ни какой разницы произойдёт это при 2,4 или 6 узлах. Суть проблемы не меняется.
Если Вы считаете что конкретно Ваша инсталяция в силу расположения или схемы включения не способна развалиться на 2 половины, то наш разговор я считаю без полезным. Всё остальное я уже описал выше.
Если Вы считаете что конкретно Ваша инсталяция в силу расположения или схемы включения не способна развалиться на 2 половины, то наш разговор я считаю без полезным. Всё остальное я уже описал выше.
я уже выше написал, что не стоит делать кластер через интернет) думаю на этом уже стоило закончить.
Я не знаю как сейчас, но раньше можно было задать вес арбитру (ArbitrationRank).
0 — не станет арбитром, 1 — станет арбитром с высоким приоритетом; 2 — нода станет арбитром только если нет претендентов с высоким приритетом.
Как раз очень удобно когда у вас появлялось 4 машины. Еще я тут свои заметки полистал, арбитром вроде бы становилась одна из нод? Т.е это машина так же может заниматься хранением данных или это можно вынести отдельно как управляющию ноду?
0 — не станет арбитром, 1 — станет арбитром с высоким приоритетом; 2 — нода станет арбитром только если нет претендентов с высоким приритетом.
Как раз очень удобно когда у вас появлялось 4 машины. Еще я тут свои заметки полистал, арбитром вроде бы становилась одна из нод? Т.е это машина так же может заниматься хранением данных или это можно вынести отдельно как управляющию ноду?
Еще хотел спросить, раньше была рекомендация писать в 1 ноду, иначе можно получить cluster-wide deadlocks.
www.percona.com/blog/2012/08/17/percona-xtradb-cluster-multi-node-writing-and-unexpected-deadlocks/
Это так же актуально?
И еще, заготовка для конфигов — это хорошо. Но можно выложить рабочии конфиги для разных нод?
Насколько я помню, надо указать для остальных нод, первую ноду, которая знает о других нодах.
Пример:
NODE1
[mysqld_safe]
wsrep_urls=gcomm://192.168.0.16:4567,gcomm://192.168.0.17:4567
NODE2
[mysqld_safe]
wsrep_urls=gcomm://192.168.0.15:4567
[mysqld]
bind-address=192.168.0.16
wsrep_node_name=node16
wsrep_sst_donor=node15
NODE3
[mysqld_safe]
wsrep_urls=gcomm://192.168.0.15:4567
[mysqld]
bind-address=192.168.0.17
wsrep_node_name=node17
wsrep_sst_donor=node15
Так же надо было отдельно инициализировать кластер пустой строкой gcomm://.
Это все еще актуально, или вопрос как то решается по другому?
P.S. Пишу как из каменного века :)
P.P.S.
www.percona.com/doc/percona-xtradb-cluster/5.5/howtos/3nodesec2.html
Раньше использовал.
www.percona.com/blog/2012/08/17/percona-xtradb-cluster-multi-node-writing-and-unexpected-deadlocks/
Это так же актуально?
И еще, заготовка для конфигов — это хорошо. Но можно выложить рабочии конфиги для разных нод?
Насколько я помню, надо указать для остальных нод, первую ноду, которая знает о других нодах.
Пример:
NODE1
[mysqld_safe]
wsrep_urls=gcomm://192.168.0.16:4567,gcomm://192.168.0.17:4567
NODE2
[mysqld_safe]
wsrep_urls=gcomm://192.168.0.15:4567
[mysqld]
bind-address=192.168.0.16
wsrep_node_name=node16
wsrep_sst_donor=node15
NODE3
[mysqld_safe]
wsrep_urls=gcomm://192.168.0.15:4567
[mysqld]
bind-address=192.168.0.17
wsrep_node_name=node17
wsrep_sst_donor=node15
Так же надо было отдельно инициализировать кластер пустой строкой gcomm://.
Это все еще актуально, или вопрос как то решается по другому?
P.S. Пишу как из каменного века :)
P.P.S.
www.percona.com/doc/percona-xtradb-cluster/5.5/howtos/3nodesec2.html
Раньше использовал.
Я выше ответил про cluster-wide deadlocks,
так же там в параметрах есть тот, который отвечает за ретраи дедлока. Проблема решается при использовании maxscale.
в заготовках для всех конфинах меняется только адрес ноды, имя ноды и список существущих нод. Текущая всегда будет последней в списке wsrep_urls
Инициировать кластер пустой gcomm:// до сих пор нужно)
так же там в параметрах есть тот, который отвечает за ретраи дедлока. Проблема решается при использовании maxscale.
в заготовках для всех конфинах меняется только адрес ноды, имя ноды и список существущих нод. Текущая всегда будет последней в списке wsrep_urls
Инициировать кластер пустой gcomm:// до сих пор нужно)
<в заготовках для всех конфинах меняется только адрес ноды, имя ноды и список существущих нод. Текущая всегда будет последней в списке wsrep_urls
Что значит текущая? Речь идет о 1 ноде? Вроде бы как в wsrep_urls мы просто перечисляем список всех нод или нет?
На других нодах мы пишет адрес первой ноды (да собственно пример выше) или я как то вас не пойму?
Можно все же пример?
Что значит текущая? Речь идет о 1 ноде? Вроде бы как в wsrep_urls мы просто перечисляем список всех нод или нет?
На других нодах мы пишет адрес первой ноды (да собственно пример выше) или я как то вас не пойму?
Можно все же пример?
первая, ее адрес 192.168.0.76
wsrep_cluster_address = gcomm://192.168.0.30,192.168.0.40,192.168.0.41,192.168.0.74,192.168.0.75,192.168.0.76
вторая, ее адрес 192.168.0.75
wsrep_cluster_address = gcomm://192.168.0.30,192.168.0.40,192.168.0.41,192.168.0.74,192.168.0.76,192.168.0.75
третья, ее адрес 192.168.0.74
wsrep_cluster_address = gcomm://192.168.0.30,192.168.0.40,192.168.0.41,192.168.0.76,192.168.0.75,192.168.0.74
итд
wsrep_cluster_address = gcomm://192.168.0.30,192.168.0.40,192.168.0.41,192.168.0.74,192.168.0.75,192.168.0.76
вторая, ее адрес 192.168.0.75
wsrep_cluster_address = gcomm://192.168.0.30,192.168.0.40,192.168.0.41,192.168.0.74,192.168.0.76,192.168.0.75
третья, ее адрес 192.168.0.74
wsrep_cluster_address = gcomm://192.168.0.30,192.168.0.40,192.168.0.41,192.168.0.76,192.168.0.75,192.168.0.74
итд
Я бы поставил innodb_locks_unsafe_for_binlog=false чтобы режим REPEATABLE-READ нормально работал. А также поставил бы innodb_flush_log_at_trx_commit=0.
innodb_flush_log_at_trx_commit=0 это перебор как мне кажется. innodb_locks_unsafe_for_binlog устарел уже в 5.6/10, но почему лучше в 0? что бы избежать фантомного чтения?
Насчет innodb_flush_log_at_trx_commit=0 может и перебор, если в датацентре свет отключат. А насчет innodb_locks_unsafe_for_binlog всё верно. Я конечно понимаю, что REPEATABLE-READ ведет к дедлокам и тормозам, но, блин, это так удобно, это как SERIALIZABLE в PostgreSQL.
Поясни почему. В MSSQL и Oracle этот режим по умолчанию, кроме того, так же как и в oracle, между снимками работает согласованное чтение. В чем минус?
Ты имеешь ввиду READ-COMMITTED по-умолчанию? При READ-COMMITTED мы можем прочитать данные согласовано только в пределах одного SQL запроса. А если запроса два — то между ними другая транзакция может навтыкать данные. И к каким последствиям это может привести — тяжело предсказать. Например в первом запросе извлек айдишники, а во втором запросе пытаешься подтянуть по ним данные (типа такой программный join осуществляешь). И всё, бабах. По некоторым айдишникам ниче не подтянулось, NullPointerException. Кто-то удалили эти записи между запросами. Придется предусматривать в коде этот случай.
READ COMMITTED Нечто похожее на уровень изоляции Oracle. Все выражения SELECT… FOR UPDATE и SELECT… LOCK IN SHARE MODE блокируют только индексные записи и не блокируют интервал перед ними. Поэтому они позволяют свободно добавлять новые записи после заблокированных. UPDATE и DELETE, которые используют уникальный индекс и уникальные условия поиска, блокируют только найденную индексную запись, и не блокируют интервал перед ней. Но в UPDATE и DELETE диапазонного типа в InnoDB должны установить блокировку следующего ключа или интервальную блокировку и блокировать добавления другими пользователями в интервал, покрытый диапазоном. Это необходимо, т.к. «фантомные строки» должны быть блокированы для успешной работы репликации и восстановления в MySQL. Согласованное чтение работает как и в Oracle: каждое согласованное чтение, даже внутри одной транзакции, устанавливает и читает свой собственный снимок.
Я бы поставил innodb_locks_unsafe_for_binlog=false чтобы режим REPEATABLE-READ нормально работал. А также поставил бы innodb_flush_log_at_trx_commit=0.
Sign up to leave a comment.
«Идеальный» кластер. Часть 3.1 Внедрение MySQL Multi-Master кластера