2013 09 23_db_lecture_02
TRANSCRIPT
Distributed CommitКурс «Базы данных»
Цесько Вадим Александровичhttp://incubos.org
@incubos
Computer Science Center
23 сентября 2013 г.
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 1 / 65
Содержание
1 Distributed Commit
2 Happens-before
3 Raft
4 Заключение
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 2 / 65
Distributed Commit Two-Phase Commit Protocol
Two-Phase Commit Protocol
Distributed atomic commitment protocolcommit или abort (rollback)Переживает (некоторые) временные сбоиПолагается на логгирование для восстановленияВосстановление — бОльшая часть логикипротокола
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 3 / 65
Distributed Commit Two-Phase Commit Protocol
Фазы
Commit-request (voting)Координатор пытается подготовить участниковтранзакцииКаждый участник отвечает Yes или No
CommitКоординатор принимает решение на основе ответовВсе сказали Yes ⇒ commit, No ⇒ abortКоординатор отправляет решение участникамУчастники применяют решение
ПредусловиеЕсли нет сбоев
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 4 / 65
Distributed Commit Two-Phase Commit Protocol
Предположения
Выделенный координаторStable storage1 + write-ahead log (WAL)Узлы не умирают навсегдаДанные в WAL не теряются и не портятсяЛюбые два узлы могут общаться
ВниманиеЕсли полностью уничтожить узел, можно потерятьданные
1http://en.wikipedia.org/wiki/Stable_storageЦесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 5 / 65
Distributed Commit Two-Phase Commit Protocol
Диаграмма
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 6 / 65
Distributed Commit Two-Phase Commit Protocol
Оптимизации
Presumed abort/commit: работает привосстановлении, экономим на логгировании,используем статистику и ожиданияTree two-phase commit protocol(Nested/Recursive 2PC): агрегация в узлах дерева,экономнее используем сетьDynamic two-phase commit: идём по дереву водну сторону, динамический выбор координатора,быстрее освобождаем ресурсы
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 7 / 65
Distributed Commit Two-Phase Commit Protocol
Ограничения
Блокирующийся протоколЕсли координатор исчезнет, то некоторые участникимогут не закончить транзакцию:
Участник отправил координатору YesКоординатор упалУчастник ожидает commit или rollback
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 8 / 65
Distributed Commit Two-Phase Commit Protocol
Поведение при сбоях
Пример ситуации:Реплика выполнила commit и упала вместе скоординаторомСистема не может восстановить результаттранзакции:
Только умершие 2 ноды знают точный результатPessimistic abort невозможен — упавшая репликамогла сделать commitPessimistic commit невозможен — изначальноерешение могло быть abort
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 9 / 65
Distributed Commit Three-Phase Commit Protocol
Three-Phase Commit Protocol
Назначение как у 2PCНеблокирующийся — ограничение сверху наcommit/abortЛучше ведёт себя при сбоях2
2PC фаза Commit разбивается на 2 фазы —получаем 3PC
2http://the-paper-trail.org/blog/consensus-protocols-three-phase-commit/Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 10 / 65
Distributed Commit Three-Phase Commit Protocol
Диаграмма
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 11 / 65
Distributed Commit Three-Phase Commit Protocol
Анализ
Вторая фаза доносит решение до всех участников⇒ состояние можно восстановить при сбоерепликиPhase 3 = 2PC CommitПри сбое координатора состояниевосстанавливается с помощью реплик:
Phase 1 (кто-то не получил Can commit?) ⇒спокойно делаем abortPhase 2 (кто-то получил preCommit) ⇒ доводимтранзакцию до commit
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 12 / 65
Happens-before Lamport timestamps
Lamport timestamps
ЦельОпределить порядок событий в распределённойсистемеa
aLamport, L. Time, Clocks, and the Ordering of Events in aDistributed System. 1978
Правила:Каждый процесс имеет счётчикИнкремент перед каждым событиемЗначение счётчика вместе с каждым сообщениемПри получении сообщенияCself = max(Cself ,Csender)
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 13 / 65
Happens-before Lamport timestamps
Формализация
C (x) — время события x∀a∀b(a 6= b ⇒ C (a) 6= C (b))Для различия событий в разных процессах частодобавляют PIDОтношение happens-before: →Clock consistency: a→ b ⇒ C (a) < C (b)Strong clock consistency: C (a) < C (b)⇒ a→ b —только через Vector ClocksНо верно, что C (a) ≥ C (b)⇒ a 6→ b
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 14 / 65
Happens-before Lamport timestamps
Анализ
Невозможно точно синхронизировать время3
Если процессы не общаются, то между ихсобытиями нет отношения порядкаОбеспечивается лишь частичный порядок
3Хотя см. http://research.google.com/archive/spanner.htmlЦесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 15 / 65
Happens-before Vector clocks
Vector clocks
ЦельВвести частичный порядок событий враспределённой системеОбнаружить нарушения причинно-следственныхсвязей
ОпределениеВекторные часы в системе с N процессами — этомассив N логических часов по одному на процесс
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 16 / 65
Happens-before Vector clocks
Правила обновления массива часов
Изначально все часы выставлены в 0При каждом событии процесс инкрементируетсвои логические часы на 1Перед отправкой сообщения процесс:
Инкрементирует свои логические часыОтправляет весь вектор вместе с сообщением
При получении сообщения процесс:Инкрементирует свои логические часыОбновляет свой вектор, беря покомпонентныймаксимум с присланным вектором
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 17 / 65
Happens-before Vector clocks
Пример
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 18 / 65
Happens-before Vector clocks
Формализация
VC (x) — векторные часы события xVC (x)z — компонента векторных часов процесса zVC (x) < VC (y)⇔ ∀z [VC (x)z ≤VC (y)z ] ∧ ∃z ′[VC (x)z ′ < VC (y)z ′]x → y ⇔ VC (x) < VC (y)VC (x) < VC (y)⇒ C (x) < C (y)Отношение happens-before антисимметрично итранзитивно
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 19 / 65
Raft Введение
МотивацияThere are significant gaps between the description of thePaxos algorithm and the needs of a real-world system...and the final system will be based on an unprovenprotocol4.
RaftПротокол консенсуса для реплицированныхавтоматовБолее простой, понятный и реализуемый чемPaxosДемонстрирует логику рассуждений
4Chandra T. D., Griesemer R., Redstone J. Paxos made live: an engineeringperspective. 2007Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 20 / 65
Raft Введение
Ссылки
Replicated State Machines5
Ongaro D., Ousterhout J. In Search of anUnderstandable Consensus Algorithm. 2013.Diego Ongaro. Raft lecture6 (Raft user study)Diego Ongaro. Paxos lecture7 (Raft user study)Множество реализаций8
5http://en.wikipedia.org/wiki/State_machine_replication6http://www.youtube.com/watch?v=YbZ3zDzDnrw7http://www.youtube.com/watch?v=JEpsBg0AO6o8https://ramcloud.stanford.edu/wiki/display/logcabin/LogCabin
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 21 / 65
Raft Введение
Replicated State Machines
Работают на множестве узловВычисляют идентичные копии одного и того жесостоянияУстойчивы к падению узловРеплицированный лог (последовательностькоманд)Решаемые задачи: выбор лидера, хранилищеконфигураций и др.Примеры: Chubby (GFS), ZooKeeper in HDFS, ...
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 22 / 65
Raft Введение
Особенности Raft
Strong LeaderКлиенты общаются только с лидеромДанные только от лидера к репликам
Leader ElectionCлучайные таймеры
Membership changesJoint consensus
Формальна описана и доказана безопасностьПроизводительность на уровне аналогов
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 23 / 65
Raft Введение
Алгоритм работы лидера
1 Получить команду от клиента2 Добавить в локальный лог3 Доставить команду другим узлам4 При успехе применить команду к своему автомату5 Вернуть ответ автомата клиенту
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 24 / 65
Raft Введение
Свойства протокола
Безопасность: никогда не вернёт некорректныйрезультат
non-Byzantine fault tolerance9
Учитывает ненадёжную сетьДоступность
Пока работают и могут общаться большинство узловУзлы останавливаются и снова подключаются
Независимость от абсолютного времениКоманда выполняется при ответе отбольшинства — устойчивость к медленным узлам
9http://en.wikipedia.org/wiki/Byzantine_fault_toleranceЦесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 25 / 65
Raft Введение
Подсистемы
Выбор лидераРепликация логаБезопасность/корректность
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 26 / 65
Raft Кластер
Кластер
Несколько узлов (3, 5, ...)Узёл в одном из трёх состояний: leader, follower,candidateВ нормальном режиме: 1 лидер и n − 1последователейПоследователи пассивны: отвечают на RPC отлидера и кандидатов
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 27 / 65
Raft Кластер
Состояния узла
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 28 / 65
Raft Кластер
Семестры
Время разбивается на семестры (terms)неопределённой длины10
Семестры нумеруются последовательноКаждый семестр начинается с выбора лидераЕсли кандидат выигрывает выборы, то он служитлидером до конца семестраЕсли никто не победил на выборах, начинаетсяновый семестр
ИнвариантВ каждом семестре не больше одного лидера
10Аналог логических часовЦесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 29 / 65
Raft Кластер
Семестры: Пример
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 30 / 65
Raft Кластер
Обнаружение устаревшей информации
Каждый узел хранит текущий семестрТекущий семестр каждый раз передаётся взапросахЕсли текущий семестр меньше пришедшего,выбираем пришедшийЕсли кандидат или лидер — step downЕсли пришедший семестр меньше текущего, тоотвергаем запрос
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 31 / 65
Raft Кластер
RPC
RequestVote — кандидат просит отдать ему голосAppendEntries — лидер реплицирует команды +heartbeat
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 32 / 65
Raft Выбор лидера
Условия запуска
Follower не получает heartbeat в течение electiontimeoutFollower увеличивает текущий семестрПереходит в состояние кандидатаПараллельно отправляет всем RequestVoteПерезапросы до получения ответа или окончаниявыборов
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 33 / 65
Raft Выбор лидера
Условия останова
Follower выиграл выборы (набрал большинствоголосов)
Каждый узел голосует единожды за семестр (FIFO)Новый лидер начинает рассылать всем heartbeats
Другой узел стал лидеромКандидат получил AppendEntries с семестром ≥текущегоКандидат переходит в состояние follower (step down)
Наступил таймаут, а победителя всё нетНикто не набрал большинства голосовКандидат переходит в состояние follower (step down)Random election timeout
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 34 / 65
Raft Репликация лога
Формат лога
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 35 / 65
Raft Репликация лога
Committed Entry
Гарантируется, что будет выполнена всемиавтоматамиВ простейшем случае — если подтвержденазапись большинством (см. записи 1-7)Лидер пересылает индекс последнего коммита вAppendEntries — followers коммитят
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 36 / 65
Raft Репликация лога
Log Matching Property
Если у двух записей в разных логах совпадают индекси семестр, то:
Они содержат одинаковую командуЛидер создаёт не больше одной записи с одниминдексом и семестромЗаписи в логе не перемещаются
Логи идентичны во всех предшествующих записяхЛидер с AppendEntries пересылает индекс и семестрпредыдущей записиFollower отвергает запрос, если не совпадаетШаг индукции
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 37 / 65
Raft Репликация лога
Но может быть так
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 38 / 65
Raft Репликация лога
Пояснения
a-b — не хватает записейc-d — лишние записиe-f — оба случая
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 39 / 65
Raft Репликация лога
Разрешение конфликтов
Замена конфликтов на followers записями логалидераЛидер помнит nextIndex для каждого follower —изначально следующий за последним в логеИспользуется RPC AppendEntries ConsistencyCheck
Если ошибка, то nextIndex - 1 и retryЕсли совпадение, то удаляется хвост и добавляютсязаписи лога лидера
Автоматическая сходимость логовЛидер никогда не удаляет и не перезаписываетзаписи в собственном логе
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 40 / 65
Raft Корректность
Проблема
Лидер закоммитил несколько записейПоследователь был недоступенЛидер ушёл с радаровПоследователь стал новым лидеромПоследователь перезаписал всем логиВ результате разные автоматы выполнили разныйнабор команд
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 41 / 65
Raft Корректность
РешениеРасширим протокол:
Ограничение на узлы, которые могут статьлидеромОграничение на записи, которые считаютсязакоммичеными
Обеспечиваем:Лидер любого семестра содержит все записи,закоммиченые в предыдущих семестрахЗаписи направлены только от лидера кпоследователямЛидеры никогда не перезатирают записи в своёмлоге
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 42 / 65
Raft Корректность
Ограничение на выбор лидера
Всё так же нужно собрать голоса большинстваНо можно стать лидером, только если наш лог неменее свежий, чем у каждого голосующегоRequestVote RPC содержит информацию опоследней записи в логеЛог новее, если семестр старше или индексбольше (лог длиннее)
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 43 / 65
Raft Корректность
Коммиты
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 44 / 65
Raft Корректность
Случай 1
Наиболее популярныйЛидер реплицирует запись из текущего семестраЗапись закоммичена, как только подтвердитбольшинствоЛидером могут стать только те, у кого есть этазапись
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 45 / 65
Raft Корректность
Коммиты
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 46 / 65
Raft Корректность
Случай 2
Лидер коммитит запись из предыдущего семестраЛидер семестра 2 создал запись по индексу 2,отреплицировал на S1 и S2 и упалS5 стал лидером в семестре 3 (собрал голоса у S3и S4)Записал запись в свой лог по индексу 2 и упалS1 стал лидером в семестре 4 (голоса от S2 и S3)Отреплицировал запись по индексу 2 на S3Незакоммичена несмотря на большинствоS5 может стать лидером (его лог новее чем S2, S3и S4) и распространить своё значение поиндексу 2
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 47 / 65
Raft Корректность
Ограничение на коммиты
Пока новый лидер не закоммитит запись изтекущего семестра, он считает предыдущиезаписи незакоммиченымиСм. случай 3 — после этого S5 не может статьлидеромСм. доказательство корректности11
11Safety proof and formal specification for Raft: http://raftuserstudy.s3-website-us-west-1.amazonaws.com/proof.pdfЦесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 48 / 65
Raft Timing and availability
Timing and availability
Timing requirementbroadcastTime � electionTimeout � MTBF
Типичные значения:broadcastTime: 0.5-20 mselectionTimeout: 10-500 msMTBF : � month
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 49 / 65
Raft Изменение конфигурации кластера
Изменение конфигурации кластера
Предполагали, что состав узлов статиченНо иногда нужно заменять сервера или изменятьуровень репликацииВ идеале — без downtimeИ автоматически — исключить человеческийфактор
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 50 / 65
Raft Изменение конфигурации кластера
Ситуация
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 51 / 65
Raft Изменение конфигурации кластера
Проблема
ПроблемаВозможно одновременное существование двух лидеровдля одного семестра в двух подкластерах
Решения:2PC: сначала выключаем старую конфигурацию,возможен downtimeRaft: промежуточная конфигурация (jointconsensus)
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 52 / 65
Raft Изменение конфигурации кластера
Идея
Комбинация двух конфигураций:Записи реплицируются серверам в обеихконфигурацияхСервер из любой конфигурации может статьлидеромНужно собрать большинство в каждойконфигурации по-отдельностиПри этом без downtime
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 53 / 65
Raft Изменение конфигурации кластера
Joint Consensus
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 54 / 65
Raft Изменение конфигурации кластера
Алгоритм
Запрос лидеру на смену конфигурации с Cold наCnew
Сохраняет в лог Cold ,new и реплицируетКаждый сервер сохраняет Cold ,new в лог и сразуначинает использоватьЛидер упал — новый лидер из Cold ,new или Cold , ноне Cnew
Успешно закоммитили — лидером может статьтолько Cold ,new
Лидер сохраняет в лог Cnew и реплицирует и т. д.Cold и Cnew не могут одновременнопринимать решения
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 55 / 65
Raft Изменение конфигурации кластера
Особенности
Если лидер входит в Cold , но не в Cnew , то долженвыйти из кластера (реплицирует, но не входит вбольшинство)Новые сервера могут быть пустыми — вначаледобавляем как неголосующих, но реплицируем наних логиУдаление серверов, которые не в курсе, что ихудаляют, может снизить производительностькластера — инициируют безнадёжные выборы
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 56 / 65
Raft Оптимизации
Log Compaction
Подходы:Очистка логов — перемещаем «живые» записи вголову и очищаем мёртвый хвост
Инкрементально и эффективноОпределение живых записей может быть сложным
Слепки — состояние системы периодическисохраняется на stable storage, а лог сбрасывается
Менее эффективно (неинкрементально)Просто
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 57 / 65
Raft Оптимизации
Snapshotting
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 58 / 65
Raft Оптимизации
Snapshotting: Нюансы
Нужно решить, когда создавать слепки —например, при достижении логом определённогоразмераCopy-on-write для асинхронной записи слепков +functional data structures/fork()
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 59 / 65
Raft Клиент
Проблема
Команда может применяться несколько разЛидер получил команду, закоммитил и умер, неуспев ответитьКлиент делает перезапрос
ИдемпотентностьКлиент присваивает командам уникальныепоследовательные номера
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 60 / 65
Raft Клиент
Проблема
Протухшее чтениеУ лидера есть все закоммиченые измененияНо в начале семестра он не знает, кто из нихзакоммиченВначале он должен закоммитить запись из новогосеместра
Решениеno-op в начале семестраHeartbeat с большинством кластера перед ответомна read
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 61 / 65
Raft Проект
Альтернативное домашнее задание
Проект akka-raft:Open-source Raft implementationScalaAkka ExtensionParameterized by Akka FSMExtended with API (spray-based)Use Case: etcd12 implementation
12https://github.com/coreos/etcdЦесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 62 / 65
Заключение Библиотечка
Библиотечка
Think Distributed: A Distributed Systems Podcast13
Наборы открытых данных для курсовой работы14
13http://thinkdistributed.io/14Via @pulser: http://www.hackathon.spb.ru/#!datasets/c1miv
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 63 / 65
Заключение Homework: Feature request 1
Homework: Feature request 1
Key-Value API (кто ещё не)Данные не влезают в память (>= 4 ГБ)Используйте открытые источники данныхСтресстест в виде shell-скрипта
СкачалиРаспаковалиЗапустили Storage (Xmx1G)Залили в Storage
Срок реализации до 2013-10-14Hints: mmap(), дисковый кэш, ...
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 64 / 65
Заключение Вопросы?
Вопросы?
http://incubos.org/contacts/Общие вопросы — в Twitter: @incubosВопросы по лекциям — в комментариях:http://incubos.org/blog/Частные вопросы — в почту[email protected]
Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 65 / 65