Когда нужно использовать репликацию?

Репликация БД: когда её использовать

Репликация — это синхронизация данных между несколькими инстанциями базы данных: одна master (primary) принимает изменения, остальные replicas (secondary) получают копию данных. Это критическая практика для высоконагруженных и надёжных систем.

Основная архитектура репликации

Master (Основная БД)
  ↓ Binlog (Binary Log с изменениями)
  ├→ Replica 1 (Копия для чтения)
  ├→ Replica 2 (Копия для чтения)
  └→ Replica 3 (Копия для резервной копии)

Сценарий 1: Высокая нагрузка на чтение (Read-Heavy приложение)

Если приложение много читает, мало пишет, репликация распределяет нагрузку.

// ❌ Без репликации (проблема: одна БД)
public class ProductService {
    private DataSource dataSource;  // Все запросы → одна БД
    
    public Product getProduct(Long id) {
        // Если 1000 пользователей одновременно читают каталог
        // одна master БД может перегрузиться
        return jdbcTemplate.queryForObject(
            "SELECT * FROM products WHERE id = ?",
            (rs, row) -> mapProduct(rs),
            id
        );
    }
}

// ✅ С репликацией (решение)
public class ProductService {
    private DataSource masterDataSource;       // Для записей
    private List<DataSource> replicaDataSources;  // Для чтения
    private LoadBalancer loadBalancer;  // Распределитель нагрузки
    
    public Product getProduct(Long id) {
        // Выбираем случайную replicas
        DataSource replica = loadBalancer.chooseReplica();
        
        return jdbcTemplate.queryForObject(
            replica,
            "SELECT * FROM products WHERE id = ?",
            (rs, row) -> mapProduct(rs),
            id
        );
    }
    
    public void updateProduct(Long id, ProductUpdate update) {
        // Записываем ТОЛЬКО в master
        jdbcTemplate.update(
            masterDataSource,
            "UPDATE products SET name = ? WHERE id = ?",
            update.getName(), id
        );
    }
}

// В реальности используй Spring Data с @Transactional(readOnly = true)
@Service
public class ProductService {
    @Autowired private ProductRepository repo;
    
    @Transactional(readOnly = true)
    public Product getProduct(Long id) {
        // Spring автоматически отправит запрос на replicas
        return repo.findById(id).orElseThrow();
    }
    
    @Transactional
    public void updateProduct(Long id, ProductUpdate update) {
        // Spring отправит запрос на master
        Product product = repo.findById(id).orElseThrow();
        product.setName(update.getName());
        repo.save(product);
    }
}

Сценарий 2: Высокая доступность и отказоустойчивость

Если master выйдет из строя, replicas помогут продолжить работу.

// ❌ Без репликации (проблема: single point of failure)
// Если master упадёт:
// - Все запросы падают
// - Приложение не может ни читать, ни писать
// - RTO (Recovery Time) = много минут

// ✅ С репликацией (решение)
public class HighAvailabilityService {
    private MasterDataSource master;
    private List<ReplicaDataSource> replicas;
    private CircuitBreaker circuitBreaker;
    
    public Product readProduct(Long id) {
        try {
            // Пытаемся прочитать из master
            return queryMaster("SELECT * FROM products WHERE id = ?", id);
        } catch (Exception e) {
            // Master недоступен → переключаемся на replicas
            return queryReplica("SELECT * FROM products WHERE id = ?", id);
        }
    }
}

// С MySQL: используй master-master репликацию для ещё большей отказоустойчивости
// Оба инстанса могут принимать и записи и чтения

Сценарий 3: Аналитика и отчёты без влияния на основную систему

Отчёты часто требуют heavy queries, которые замораживают основную БД.

// ❌ Неправильно (отчёты нагружают production БД)
public class ReportService {
    private DataSource productionDb;
    
    public List<SalesReport> generateMonthlyReport(YearMonth month) {
        // Этот запрос может работать 10 минут
        // и блокировать production трафик
        return jdbcTemplate.query(
            productionDb,
            "SELECT product_id, SUM(amount) as sales " +
            "FROM sales WHERE year = ? AND month = ? " +
            "GROUP BY product_id",
            // ...
        );
    }
}

// ✅ Правильно (отчёты на replicas)
public class ReportService {
    @Autowired @Qualifier("replicaDataSource")
    private DataSource analyticsReplica;
    
    public List<SalesReport> generateMonthlyReport(YearMonth month) {
        // Запрос выполняется на отдельной replicas
        // Production не пострадает
        return jdbcTemplate.query(
            analyticsReplica,
            "SELECT product_id, SUM(amount) as sales " +
            "FROM sales WHERE year = ? AND month = ? " +
            "GROUP BY product_id",
            // ...
        );
    }
}

Сценарий 4: Миграция без downtime

Репликация позволяет перенести данные без остановки приложения.

Шаги миграции:
1. Создаём новый инстанс БД
2. Настраиваем репликацию: старая БД → новая БД
3. Ждём полной синхронизации
4. Переключаем приложение на новую БД (fast operation)
5. Старая БД становится replicas (backup)

// После миграции приложение на новой БД
public class DataSourceConfig {
    @Bean
    public DataSource primaryDataSource() {
        // Теперь это новый инстанс
        return createDataSource(
            "new-db-host:5432",
            "production_db"
        );
    }
}

Сценарий 5: Географическое распределение (Multi-Region)

Репликация в разные регионы уменьшает latency для глобальных пользователей.

Основная БД (Tokyo)
  ↓ Реплика (Singapore)  — для азиатских пользователей
  ↓ Реплика (Sydney)     — для австралийских пользователей  
  ↓ Реплика (Frankfurt)  — для европейских пользователей

// Геолокация для выбора ближайшей replicas
public class GeoLoadBalancer {
    private Map<String, DataSource> replicasByRegion = new ConcurrentHashMap<>();
    
    public DataSource chooseReplica(String userRegion) {
        // Пользователь из Tokyo → читаем из Tokyo replicas
        return replicasByRegion.getOrDefault(
            userRegion,
            replicasByRegion.get("default")  // fallback
        );
    }
}

Сценарий 6: Требования compliance и резервные копии

Некоторые регуляции требуют данные хранить в разных местах.

// Финансовая компания: данные должны быть
// - В DC1 (основная)
// - В DC2 (backup в другом городе)
// - В DC3 (compliance архив в стране X)

public class ComplianceDataService {
    private DataSource dc1Primary;      // Primary
    private DataSource dc2ReplicaBackup;   // Горячий backup
    private DataSource dc3Archive;      // Архив для compliance
    
    public void persistFinancialRecord(Record record) {
        // Записываем на все три инстанса
        persist(dc1Primary, record);
        persist(dc2ReplicaBackup, record);
        persist(dc3Archive, record);
    }
}

Решения для репликации в Java экосистеме

Родная репликация БД:

• MySQL — Master-Slave, Master-Master, Group Replication
• PostgreSQL — Streaming Replication, Logical Replication
• MongoDB — Replica Sets

框架/Библиотеки для управления:

<!-- ShardingSphere для автоматической маршрутизации read/write -->
<dependency>
    <groupId>org.apache.shardingsphere</groupId>
    <artifactId>shardingsphere-jdbc</artifactId>
    <version>5.2.0</version>
</dependency>

// Автоматическая маршрутизация
@Bean
public DataSource shardingDataSource(
        DataSource masterDataSource,
        List<DataSource> replicaDataSources) throws SQLException {
    
    Map<String, DataSource> dataSourceMap = new HashMap<>();
    dataSourceMap.put("master", masterDataSource);
    for (int i = 0; i < replicaDataSources.size(); i++) {
        dataSourceMap.put("replica_" + i, replicaDataSources.get(i));
    }
    
    // ShardingSphere автоматически маршрутирует запросы
    return ShardingSphereDataSourceFactory.createDataSource(dataSourceMap);
}

Когда НЕ нужна репликация:

• Маленькие приложения с низкой нагрузкой
• Данные, которые не критичны
• Single-server deployment
• Очень высокие требования к консистентности (eventual consistency неприемлема)

Ключевые преимущества:

• Масштабируемость чтения — N replicas для N запросов
• Отказоустойчивость — система работает если master упадёт
• No single point of failure — данные распределены
• Аналитика без влияния — heavy queries на отдельной replicas
• Миграции без downtime — плавный переход

Правило: Используй репликацию, если приложение читает значительно больше, чем пишет, или требует high availability.