Failover – это переключение Мастер узла, когда одна из Реплик берет на себя ответственность Мастера, когда текущий Мастер упал.
Для этого Реплика должна хранить одни и те же данные с Мастером, реализовать это нужно с помощью синхронной репликации.
Hot standby – Реплика которая использует синхронную репликацию и хранит одни и те же данные, что и Мастер.
А также он готов взять на себя ответственность если мастер из сети пропадет.
Split Brain – возвращение мертвеца.
Когда сервис восстановился после того как пропал из сети и снова попал в кластер.
В такой момент в кластере есть 2 МАСТЕРА.
В такой момент выбирает заново мастер по какому-то алгоритму:
1) через голосование
2) поколения - у кого большее поколения, тот мастер
Основные типы конфликтов Master-Master:
· Конфликты при совместном изменении общих данных.
Пример: пост в сообществе может быть изменен админами одновременно, подключенными к разным ЦОДам.
· Конфликты временных меток (ordering conflicts).
Например, пользователь из одного ЦОДа пишет сообщение раньше, но его сообщение приходит в систему позже, чем сообщение из другого ЦОДа.
· Конфликты с идентификаторами.
Например, два пользователя из разных ЦОДов создали посты в одно время (одновременно) и у постов выставился один и тот же id в разных ЦОД, после того как ЦОДы стали синхронизироваться появился конфликт.
Решение конфликтов в Master-Master или MultiMaster системе:
· LWW (Last Write Wins) - всегда берем последнее записанное значение
· Ранжирование реплик по рангам – при синхронизации выиграет узел с наивысшим рангом (Просто присваиваем каждому мастеру свой ранг)
· Решение конфликтов на клиенте – клиент сам решает, как мержить данные с разных узлов при наличии расхождений (Типо как GIT мержим сами ветки и решаем какие правки верные. Этот механизм часто используется в NoSql базах, тк они не поддерживают консистентность/согласованность данных и разрешения конфликтов на своей стороне)
· CRDT (дельта изменений) (Conflict-replicated data types) – вместо конкретного значения при модификации записываем дельту (Использование специфичных данных, один из них это ДЕЛЬТА, который хранит разницу, например, для вычета/добавления средств после оплаты/перевода)
Варианты решения конфликтов с одинаковыми идентификаторами:
· Глобально уникальные идентификаторы (UUID).
UUID не требует центрального сервера и генерируется на любом ЦОД.
· Комбинированные идентификаторы (Namespace + Local Id)
· Time-based идентификаторы (Snowflake ID использует Twitter) – включает: 1) Метку времени (с точностью до миллисекунд), 2) ID-ЦОДа (или машины), 3) Инкрементный счетчик для разрешения конфликтов в пределах одного миллисекундного интервала
Формат передающихся данные для репликации:
1) Statement base (SBR) – передаются непосредственно запросы на языке запросов, используемом в БД.
Каждый запрос применяется на каждом узле.
Передаются SQL запросы INSERT/UPDATE, но есть такие данные которые берутся из функций, в итоге эти данные могут расходиться на реплике и на мастере - например, функция получения текущего времени, например, в PostgreSQL "now()".
2) Row based (RBR) – передаются изменения строк в бинарном формате.
Строки передаются целиком даже при изменении отдельного поля, но это обычно можно настроить.
Здесь данные уже всегда будут одинаковые, но может возникнуть проблема при массовом обновлении данных - у всех пользователей обновить статус, здесь у "Statement base" был бы всего один запрос маленький, а в этом варианте будут передаваться огромные данные.
Вывод - при массивных запросах "Row based" будет проигрывать "Statement base".
3) Mixed – переключение между SBR и RBR в зависимости от ситуации.
При больших запросах, когда будет обновляться много данных - будет использоваться "Statement base", а когда нужны транзакционные изменения с некоторыми строками будем передавать сами строки, то есть использовать "Row based".
Варианты реализации репликации:
- Физическая (Слейв идентичен Мастеру на бинарном уровне) – передается информация о физическом изменении страниц БД;
Общий принцип:
· Мастер сервер записывает изменения данных в журнал транзакций (WAL);
· Слейв сервер копирует события журнала транзакций;
· Слейв сервер воспроизводит изменения из журнала транзакций;
Плюсы:
· Слейв сервер идентичен Мастеру;
· Практически отсутствуют накладные расходы;
Минусы:
· Если данные на мастере были испорчены из-за сбоев RAM, то на слейв сервере также будут испорченные данные;
В отличии от логической, такого не произойдет, тк SQLзапрос не выполнится просто.
· На реплике не может быть локальных изменений схемы данных;
· Не возможна мастер-мастер репликация;
- Логическая (Передаются измененные записи) – передается информация об изменении записей в БД с помощью SQL запросов (SBR) или в бинарном формате (RBR);
Общий принцип:
· Мастер сервер записывает изменения данных в журнал транзакций (WAL);
· На базе журнала транзакций мастер сервер восстанавливает информацию об изменении записей;
· Данные об изменении записей передаются на Слейв сервер для воспроизведения;
Плюсы:
· Более компактный обмен данными;
· Если данные на Мастере были испорчены из-за сбоев RAM, то репликация остановится;
· На Мастере и Слейв сервере можно использовать разную схему данных;
Минусы:
· Более высокая нагрузка на Слейв сервер;
· Нет хорошего решения проблемы репликации DDL-запросов (ALTER, CREATE, DROP, RENAME и тд);
Как бороться с задержками или неправильным порядком
создания данных при репликации?
1) Чтение собственных записей - отправляем запросы на чтение на Master сервер, если прошло мало времени - меньше чем задержка при репликации (как вычислить какая скорость репликаций?)
2) Монотонное чтение - каждый клиент всегда читает из одного и того же сервера.
Не будет такого момента, что один раз он прочитал с Мастера, в другой раз с Реплики - все данные будут одинаковые у пользователя.
Да он не получит обновленные данные сразу, но зато у него не будет таких мигающихся изменений, что изменения появились, а потом исчезли.
3) Согласованное префиксное чтение - гарантируем, что БД всегда применяет операции в одном и том же порядке.
Возникает в Master-Master системах, когда пользователь может получить данные в неправильном порядке, нарушая логическую последовательность событий.
Это самое сложное в реализации решение, тк должна соблюдаться причина следственная связь.
Пример: кто-то опубликовал пост, а другой пользователь написал комментарий к нему, при этом комментарий он видит, а к какому посту он был написан НЕТ, тк поста еще на реплике не имеется)
Самое легкое решение – сортировка по монотонному полю, которое отслеживает порядок событий, например, по временной метке.
Системы обработки данных:
- OLTP (Online Transaction Processing) – обработка транзакций (в первую очередь традиционные реляционные БД).
Выполняет большое кол-во транзакций в режиме реального времени большему кол-ву людей.
Примеры: Интернет магазин, банк.
Время отклика – несколько мс.
- OLAP (Online Analytical Processing) – обработка аналитических запросов (в первую очередь колоночные БД).
Для OLAP обычно применяют ETL (Extract, Transform, Load) – собираем данные из нескольких источников в одно хранилище.
Примеры: Аналитика продаж.
Время отклика может занимать приемлемое время.
- HTAP (Hybrid Transactional/Analytical Processing) – гибдридная модель, совмещающая в себе две предыдущие за счёт использования нескольких движков обработки и хранения.
Пример: YDB
Суть разделения OLAP и OLTP – некоторые думаю, что при большом количестве чтении данных, постоянной нагрузке на выполнение объемных запросов нужно уметь МАСШТАБИРОВАТЬ OLTP базу, но на самом деле для этого нужно выделить отдельную систему OLAP, которая всю нагрузка заберет на себя.
Конкурентный доступ (когда используют уровни изоляции)
Это то как происходят блокировки данных, когда используют уровни изоляции.
По сути основных механизмом существует всего два – TO и MVCC, но указал три.
· 2PL (2-phase locking) – двухфазная блокировка, сначала получим все нужные блокировки, а в конце, когда все работы выполнены, все блокировки снимаются;
Если напрямую реализовывать это, то с легкостью можно получить deadlock.
· MVCC (multiversion concurrency control) – у изменяемых объектов существует несколько доступных версий, видимая версия зависит от уровня изоляции.
Идет сравнение версии транзакции с номерами версией, которые они видят в БД. Если есть более новая версия, то транзакция возьмет просто более позднюю.
· TO (Timestamp ordering) – каждой транзакции присвоена метка времени, доступность определяется упорядоченностью по времени.
Логика одна и та же как у ТО, просто вместо версий используется время.