Что такое репликация данных в базах данных и зачем она нужна?

А, слушай, смотри, про репликацию данных. Ну это ж, блядь, как в жизни — чтобы не остаться с одной жопой на всю деревню. Суть в том, что ты копируешь данные и раскидываешь их по разным серверам, чтобы если один накроется медным тазом, остальные продолжали работать. Доступность, отказоустойчивость и всё такое, понимаешь?

Ну, основные модели, как это бывает

1. Мастер-Слейв (Главный и Подчинённый)

• Мастер (Главный): Единственный пахан, который может что-то писать, изменять, удалять. Все операции записи — только к нему.
• Слейв (Реплика, Читалка): Его подручные. Они только читают, как говно в книжке, и обслуживают запросы SELECT. Писать им нельзя — не их епархия.

Как работает: Мастер записывает все свои изменения в специальный журнал (бинарный лог, WAL), а реплики потом, как послушные псы, подтягивают эти изменения к себе. Можно синхронно (ждать подтверждения) или асинхронно (похуй, сделаю потом).

Что хорошего:

• Чтение масштабируется: Ты можешь навешать кучу реплик и весь читательский трафик на них скинуть. Мастеру легче.
• Резервная жопа есть: Если мастер вдруг ебнулся, одну из реплик можно сделать новым мастером. Не останешься у разбитого корыта.
• Для аналитики: Все эти тяжёлые отчёты гоняй на реплике, а мастер пусть живёт спокойно и пишет.

Вот, смотри, как в Spring Boot это может выглядеть, чтоб не ебать мозги:

@Configuration
public class DatabaseConfig {

    // Это наш главный, для записи
    @Bean
    @Primary
    @ConfigurationProperties("spring.datasource.master")
    public DataSource masterDataSource() {
        return DataSourceBuilder.create().build();
    }

    // А это подчинённый, для чтения
    @Bean
    @ConfigurationProperties("spring.datasource.slave")
    public DataSource slaveDataSource() {
        return DataSourceBuilder.create().build();
    }

    // А вот хитрая жопа — маршрутизатор, который сам решает, куда идти
    @Bean
    public DataSource routingDataSource(
            @Qualifier("masterDataSource") DataSource master,
            @Qualifier("slaveDataSource") DataSource slave) {

        AbstractRoutingDataSource router = new AbstractRoutingDataSource() {
            @Override
            protected Object determineCurrentLookupKey() {
                // Смотрит, читаем мы или пишем
                return TransactionSynchronizationManager.isCurrentTransactionReadOnly() 
                        ? "slave" 
                        : "master";
            }
        };

        Map<Object, Object> targetDataSources = new HashMap<>();
        targetDataSources.put("master", master);
        targetDataSources.put("slave", slave);

        router.setTargetDataSources(targetDataSources);
        router.setDefaultTargetDataSource(master); // На всякий пожарный — мастер
        return router;
    }
}

// А в сервисе вообще красота
@Service
public class UserService {

    @Transactional // Эта аннотация скажет — иди на мастер, будем писать
    public User createUser(User user) {
        return userRepository.save(user);
    }

    @Transactional(readOnly = true) // А эта — иди на слейв, только читай
    public User getUser(Long id) {
        return userRepository.findById(id).orElse(null);
    }
}

2. Мастер-Мастер (Мульти-Главный)

• Тут уже несколько паханов, и каждый может принимать запись. Изменения потом как-то синхронизируются между ними.
• Сложность, блядь, пиздец: Если в двух разных местах одновременно изменить одну и ту же запись — будет конфликт. Кто кого? Нужны специальные механизмы, чтобы решать, чья правда круче.
• Где применяется: Ну, например, когда сервера в разных концах земли, чтобы запись была быстрее для всех.

3. Шардирование (Разделяй и властвуй)

• Это когда ты горизонтально делишь данные. Одни строки таблицы — на одном сервере, другие — на другом. По какому-то ключу, например, по user_id.
• Решает проблему масштабирования записи, потому что запись теперь тоже можно распределить.
• Часто его ещё и с репликацией комбинируют: каждый шард сам по себе может иметь своих подчинённых-реплик. Овердохуища получается.

Синхронно или асинхронно? Вот в чём, блядь, вопрос

• Синхронная репликация: Мастер, прежде чем сказать клиенту «всё ок», ждёт, пока реплики подтвердят, что они тоже записали данные. Гарантирует, что везде полная согласованность, но если реплика сдохла — мастер может встать колом и ждать. Производительность, понятное дело, страдает.
• Асинхронная репликация: Мастер сразу говорит клиенту «готово», а репликам шлёт данные потом, когда сможет. Производительность — огонь, доступность — топ, но есть нюанс: реплики могут немного отставать. Это называется replica lag. То есть на реплике данные могут быть чуть старше, чем на мастере. Но обычно это не страшно, если, конечно, ты не делаешь систему для ядерного реактора.

Итог, ёпта: Репликация — это фундамент для того, чтобы твоя система не развалилась как карточный домик от первой же нагрузки или сбоя. Без неё — пиши пропало.