Как называется процесс в репликации, когда Master умер и выбирается Slave?

Процесс выбора нового мастера после отказа основного

Процесс, который вы описываете, называется "failover" (файловер) или более точно — "leader election" (выбор лидера) в контексте систем репликации баз данных. Это критически важный механизм для обеспечения высокой доступности и отказоустойчивости распределенных систем.

Детальное объяснение процесса failover

Когда мастер-узел (primary) в классической master-slave репликации выходит из строя, система должна автоматически или вручную выполнить следующие шаги:

1. Обнаружение отказа (Failure Detection):

    *   Slave-узлы (реплики) или отдельный мониторинговый сервис перестают получать heartbeat или ответы на запросы от мастера.
    *   После истечения таймаута узел считается недоступным.

1. Инициация процедуры выбора (Election Initiation):

    *   Запускается алгоритм консенсуса (например, Raft, Paxos) или используется простой механизм определения узла с наибольшим идентификатором (ID).
    *   В системах с автоматическим failover (как в **Redis Sentinel** или **Patroni для PostgreSQL**) специальные демоны-арбитры координируют этот процесс.

1. Критерии выбора новой мастер-реплики:

    *   **Свежесть данных (Replication lag)**: Предпочтение отдается slave с минимальным отставанием (lag) от умершего мастера.
    *   **Приоритет (Priority)**: Узлам могут быть присвоены веса для управления порядком выбора.
    *   **Расположение (Location)**: Для уменьшения задержки может выбираться реплика в том же дата-центре.

Пример автоматического failover в Redis Sentinel

Вот как выглядит конфигурация и логика Sentinel для автоматического переключения:

# Конфигурация Sentinel (sentinel.conf)
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster ¢000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

// Пример логики на Go, имитирующей выбор новой мастер-реплики
package main

import (
    "fmt"
    "sort"
)

type Replica struct {
    ID       int
    Lag      int64 // Отставание в миллисекундах
    Priority int
    Healthy  bool
}

func electNewMaster(replicas []Replica) *Replica {
    // Фильтруем только здоровые реплики
    var candidates []Replica
    for _, r := range replicas {
        if r.Healthy {
            candidates = append(candidates, r)
        }
    }
    
    if len(candidates) == 0 {
        return nil
    }
    
    // Сортируем по приоритету и отставанию
    sort.Slice(candidates, func(i, j int) bool {
        if candidates[i].Priority == candidates[j].Priority {
            return candidates[i].Lag < candidates[j].Lag
        }
        return candidates[i].Priority > candidates[j].Priority
    })
    
    return &candidates[0]
}

func main() {
    replicas := []Replica{
        {ID: 1, Lag: 100, Priority: 10, Healthy: true},
        {ID: 2, Lag: 50, Priority: 5, Healthy: true},
        {ID: 3, Lag: 2000, Priority: 8, Healthy: false}, // Не здоров
    }
    
    newMaster := electNewMaster(replicas)
    if newMaster != nil {
        fmt.Printf("Выбран новый мастер: ID=%d, Lag=%dms\n", 
                   newMaster.ID, newMaster.Lag)
    }
}

Ключевые проблемы и решения при failover

• Split-brain (раскол мозга): Ситуация, когда два узла считают себя мастерами. Решается через кворум и алгоритмы консенсуса.
• Потеря данных (Data loss): Если slave с наименьшим lag всё равно отстал на несколько транзакций. Используется синхронная репликация для критически важных данных.
• Обновление конфигурации клиентов: Клиенты должны узнать о новом мастере. Решается через:

    *   **Виртуальный IP (VIP)**, который перемещается на новый мастер
    *   **Сервис открытия (Service Discovery)** типа Consul или etcd
    *   **Прокси-слой** (HAProxy, ProxySQL)

Различные реализации в популярных системах

Заключение

Процесс failover — это комплексная процедура, требующая тщательного проектирования для минимизации простоя и предотвращения потери данных. В современных облачных средах этот процесс часто интегрирован в managed-сервисы (AWS RDS, Google Cloud SQL), где провайдер полностью управляет отказоустойчивостью. При проектировании собственных систем разработчикам Go необходимо учитывать сетевые задержки, консенсус-алгоритмы и обеспечение идемпотентности операций при переключении.