Какие риски связаны с Galera Active-Active для одной таблицы с непрерывным чтением и записью? - PullRequest
0 голосов
/ 05 ноября 2018

Я рассматриваю возможность использования Galera Active-Active с пятью узлами MySQL. Узлы располагаются за балансировщиком нагрузки, и приложение может выполнять запись в любой из узлов.

Мое приложение читает / записывает / обновляет одну и ту же таблицу примерно 1000 раз в секунду. Записи обычно составляют около 100 тыс. Данных.

Типичная логика БД будет такой:

(1) выберите, чтобы увидеть, существуют ли данные в базе данных

(2), если нет, введите данные

(3) больше обработки

(4) обновить некоторые данные

Выбор (1) будет происходить около 75 миллионов раз в день. Вставки (2) и обновления (4) около 1 миллиона раз в день.

A. Правильно ли я думаю, что Galera будет постоянно блокировать таблицу, вызывая медленную запись и обновление?

B. Правильно ли я считаю, что синхронизация данных между узлами может занять несколько секунд или дольше, поэтому существует риск, что select (1) сообщит, что данные еще не вставлены, но фактически вставка (2) уже выполнена , но он еще не синхронизирован со всеми узлами?

1 Ответ

0 голосов
/ 06 ноября 2018

Во-первых, помните, что (1) может быть только консультативным. То есть (1) может сказать «данные не существуют», но тогда (2) найдет, что данные там есть. Или это открытие не произойдет до тех пор, пока COMMIT?

Пожалуйста, добавьте в свой список любые START TRANSACTION и COMMIT. Между тем, я предполагаю, что все 4 шага находятся в одной транзакции, хотя я бы предложил поместить (1) вне транзакции.

Насколько далеко (время пинга) находятся узлы? Если они находятся в одном здании, синхронизация может занять всего миллисекунды. (Я говорю « может », потому что 1K действий в секунду, вероятно, будет несколько стрессовым.)

Я думаю, что это может быть лучше:

(1) See if row exists -- 98% of the time, this will avoid doing the rest.
BEGIN;
(2), (3), (4);  -- check after each step; 1% of collisions will be caught here
COMMIT;  -- again check; still another 1% get caught here.

То есть отказаться от стремления к совершенству (один тест ловит 100%). Вместо этого, играйте в игру чисел так, чтобы вы обычно делали то, что вам нужно, а затем нередко выявляли нечетные случаи, чтобы заметно не повредить производительности.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...