В NuoDB 2.0.1 регион — это свойство, которое представляет географическое расположение базы данных. Такие местоположения могут включать дата-центр в крупном городе, стране или здании . Одна база данных NuoDB может иметь несколько разных регионов. В дополнение к представлению местоположения, регионы также могут использоваться для обеспечения согласованности базы данных, ограничивая транзакции записи для завершения только тогда, когда указанное количество регионов наблюдало запись. Это ограничение уровня транзакции называется «фиксация на уровне региона».
В этой статье описывается, как настроить базу данных NuoDB для включения географических регионов и фиксаций на уровне регионов. Чтобы продемонстрировать эту функциональность, мы запустили эту настройку для Jepsen ( специфический для nuodb форк ), стресс-тест распределенной базы данных. Jepsen подвергает базы данных сетевым разделам, пока клиенты выполняют вставки. Другие сообщения о запуске Jepsen против NuoDB можно найти по адресу: Jepsen Part 1 и Jepsen Part 2 .
Обеспечение регионов
Подготовка региона начинается с брокера NuoDB и / или агента. Для простоты в этой статье брокеры будут использоваться только в примерах, однако те же этапы настройки применимы и к агентам. Брокеры могут принять следующий флаг, обозначающий их регион:
--region <name>
Имя — это произвольная строка, представляющая физическое местоположение, связанное с брокером. Например, можно указать, что брокер работает в Нью-Йорке, назначив строку «NYC» в качестве аргумента региона. Полная команда выглядит следующим образом:
java -jar /opt/nuodb/jar/nuoagent.jar --bin-dir /opt/nuodb/bin --broker --port 17600 --domain inventory --password foo --region NYC
Эта команда предоставляет принимающей стороне регион Нью-Йорк. Последующие механизмы транзакций NuoDB (TE) и менеджеры хранилищ (SM), запущенные на этом хосте, будут принадлежать региону Нью-Йорка.
Регион на уровне региона
Одной из проблем для базы данных, которая охватывает несколько регионов, является обеспечение согласованности данных в этих регионах. Если база данных работает в разных регионах, данные, записанные в один регион, должны быть в конечном итоге записаны во все другие регионы. На уровне транзакции может быть желательно гарантировать, что транзакция записи не завершится, пока она не получит подтверждение от одного или нескольких одноранговых регионов. Например, транзакция, которая вставляется в базу данных инвентаризации, может потребовать подтверждения того, что вставка произошла как минимум в двух центрах обработки данных, прежде чем она сможет зафиксировать. NuoDB обеспечивает фиксацию на уровне региона для применения этого ограничения уровня записи.
Чтобы включить фиксацию на уровне региона, каждый TE и SM в базе данных должны работать со следующим аргументом:
--commit region:<n>
Этот аргумент указывает, что транзакции записи не могут фиксироваться до тех пор, пока по крайней мере n регионов не подтвердят запись. Ниже приведен пример использования этого аргумента для запуска SM:
java -jar nuodbmanager.jar --broker host1.foo.com --password bar --command "start process sm host host1.foo.com database inventory archive /var/archive initialize yes options '--commit region:2'"
Джепсен
В этом разделе описываются результаты стресс-теста Jepsen, выполненного для базы данных NuoDB, настроенной с тремя регионами и настроенной с требованием фиксации на уровне региона как минимум из двух регионов. Цель этого эксперимента — показать, как работающая база данных NuoDB может выдержать потерю одного региона при обработке транзакций вставки. Реальной аналогией этого эксперимента является вставка базы данных для обработки в трех крупных городах США, когда один город полностью изолирован из-за серьезного сбоя сети.
Настройка NuoDB
База данных была настроена для работы на пяти разных хостах, представляющих центры обработки данных в городах США, Нью-Йорке, Лос-Анджелесе и Бостоне:
- nyc1.nuodb.com
- nyc2.nuodb.com
- la1.nuodb.com
- la2.nuodb.com
- bos.nuodb.com
Каждому хосту был предоставлен брокер NuoDB с использованием флага —region, соответствующего его региону:
dottavio@nyc$ java -jar nuoagent.jar --bin-dir /opt/nuodb/bin --broker --port 17600 --domain jepsen --password jepsen --region NYC dottavio@la$ java -jar nuoagent.jar --bin-dir /opt/nuodb/bin --broker --port 17600 --domain jepsen --password jepsen --region LA dottavio@bos$ java -jar nuoagent.jar --bin-dir /opt/nuodb/bin --broker --port 17600 --domain jepsen --password jepsen --region BOS
Области Нью-Йорка и Лос-Анджелеса содержали один SM и два TE. Область BOS, представляющая меньший центр обработки данных, имела один SM и один TE. Каждый SM и TE использовали флаг региона —commit следующим образом:
# SM example java -jar /opt/nuodb/jar/nuodbmanager.jar --broker nyc.foo.com --password jepsen --command "start process sm host nyc.nuodb.com database jepsen archive /var/archive initialize yes options '--ping-timeout 30 --commit region:2'"
# TE example java -jar /opt/nuodb/jar/nuodbmanager.jar --broker nyc.foo.com --password jepsen --command "start process te host nyc.nuodb.com database jepsen options '--ping-timeout 30 --commit region:2'"
Если указать фиксацию «2» для региона, транзакции записи будут фиксироваться только в том случае, если доступны 2 из 3 городов (т. Е. Регионов).
Аргумент —ping-timeout включает систему обнаружения ошибок NuoDB. Эта функция отключит неосновные разделы базы данных при возникновении сетевых разделов. В контексте этого эксперимента, если области базы данных станут изолированными, они будут удалены из базы данных. Более подробное описание обнаружения сбоев в NuoDB см. В нашей записи технического журнала Failure Detection .
Запрос к системной таблице NuoDB показывает более подробное описание базы данных и ее регионов:
выберите адрес, порт, георегион в порядке system.nodes по георегиону;
ADDRESS TYPE GEOREGION -------------------- ----------- ---------- bos.nuodb.com Storage BOS bos.nuodb.com Transaction BOS la1.nuodb.com Storage LA la2.nuodb.com Transaction LA nyc1.nuodb.com Transaction NYC nyc2.nuodb.com Storage NYC
Работает Джепсен
Jepsen был настроен на разделение региона Лос-Анджелеса от Нью-Йорка и ЛС. Командная строка для запуска jepsen была следующей:
lein run nuodb -f partition -u <username> -p <passwd> -X insert -t 17600
Приведенная выше команда запускает jepsen против использования NuoDB с использованием вставок на порту 17600. Аргумент ‘-f partition’ указывает, что сетевой раздел (т. Е. Область LA) будет возникать во время генерации вставок.
Вывод jepsen из теста включен ниже. Каждая строка в выводе представляет попытку вставки клиентом jepsen. В первом столбце указывается количество вставок, за которым следует состояние вставки, а также продолжительность вставки в миллисекундах.
Сетевой раздел произошел после вставки # 105. После сетевого раздела клиенты, подключенные к региону Лос-Анджелеса, в конечном итоге истекают. Это связано с тем, что NuoDB обнаружил ошибку при удалении области LA из базы данных. Ошибки вставки представляют соединения с областью LA, всего их шесть. Сводка результатов jepsen показывает, что 1994 вставки из 2000 были должным образом признаны.
Run will take 200 seconds 0 :ok 9 ▏ 1 :ok 79 ▎ 2 :ok 91 ▎ ... ... ... 103 :ok 4 ▏ 104 :ok 2 ▏ 105 :ok 3 ▏ Partitioned. 106 :error 65006 107 :ok 3 ▏ 108 :error 65005 109 :error 65006 110 :ok 3 ▏ 111 :error 65003 112 :ok 4 ▏ 113 :ok 4 ▏ 114 :ok 32562 115 :ok 3 ▏ 116 :ok 3 ▏ 117 :ok 3 ▏ 118 :ok 3 ▏ 119 :error 65004 120 :ok 5 ▏ 121 :ok 5 ▏ 122 :ok 5 ▏ 123 :ok 4 ▏ 124 :error 65004 125 :ok 3 ▏ 126 :ok 3 ▏ 127 :ok 3 ▏ ... ... ... 1995 :ok 4 ▏ 1996 :ok 4 ▏ 1997 :ok 4 ▏ 1998 :ok 4 ▏ 1999 :ok 3 ▏ 0 unrecoverable timeouts Collecting results. Writes completed in 200.052 seconds 2000 total 1994 acknowledged 1994 survivors all 1994 acked writes out of 2000 succeeded. 🙂
Повторная проверка системной таблицы показывает, что область LA была удалена системой обнаружения сбоев NuoDB.
выберите адрес, тип, георегион из системы. порядок узлов по георегиону;
ADDRESS TYPE GEOREGION -------------------- ----------- ---------- bos.nuodb.com Storage BOS bos.nuodb.com Transaction BOS nyc1.nuodb.com Storage NYC nyc2.nuodb.com Transaction NYC
Резюме
Фиксация на уровне региона предоставляет пользователям гибкость NuoDB на уровне транзакций в отношении согласованности записи в географически разделенных регионах. В предыдущих разделах мы показали, как настроить базу данных NuoDB с помощью этой новой опции региона. Помимо разделения базы данных на отдельные регионы, можно гарантировать, что на уровне транзакций записи будут подтверждены из минимального подмножества этих регионов. Простой вариант использования этой функции — управление базой данных, охватывающей несколько крупных городов США. В этом сценарии использования транзакции на основе записи фиксируются только тогда, когда по крайней мере два из трех городов подтверждают запись. Когда один из трех городов разделен (из-за сбоя сети), последующие транзакции записи продолжатся в остальных городах. Используя Jepsen, мы продемонстрировали устойчивость NuoDB к сбоям в сети, когда разорваны соединения между регионами.