Катастрофы больше не страшны: как мы сделали асинхронную транзакционную репликацию в GridGainБазы данных и системы хранения
Старший разработчик в GridGain Systems, участник сообщества Apache Software Foundation, коммиттер в проекте Apache Ignite. Область экспертизы в Ignite - persistence, crash recovery и структуры данных.
До этого занимался разработкой высоконагруженной трейдинговой платформы (Java).
Современные распределенные системы достаточно живучи. Благодаря тому, что данные в кластере хранятся в нескольких копиях, выход из строя одного узла или даже целой стойки серверов в дата-центре не влияет на работоспособность сервиса. Но что если катастрофа затронет весь кластер целиком? Как защититься от непредвиденного падения всей системы, отключения света в дата-центре и, само собой, человеческого фактора? Когда ваш бизнес зависит от жизни кластера, хорошо на всякий случай иметь запасной — помимо опции переключения в случае аварии, на нём можно считать метрики и аналитику. В случае, когда ваш прикладной код использует транзакции для поддержки необходимых инвариантов, будет ещё лучше, если replica-кластер сохранит транзакционную целостность.
Из доклада вы узнаете, как мы сделали всё это возможным в GridGain, а именно:
— Какие варианты репликации возможны и какие применяются в существующих решениях;
— Как начать репликацию, сделав два кластера эквивалентными, и как поддерживать актуальное состояние replica-кластера;
— Как обеспечить транзакционную целостность на replica-кластере;
— Как поменять кластера ролями - плановое переключение (с продолжением репликации в обратную сторону) и аварийное переключение;
— Что делать, если кластера начинают шалить, причём каждый по-своему — хэндлинг выхода узлов на master и replica кластере;
— Мета-репликация: как улучшить usability, реплицируя не только данные, но и изменения бинарных схем пользовательских данных и даже изменения топологии кластера.