Настройка репликации данных и управление версиями схем баз данных

Настройка репликации данных

Репликация данных позволяет создать несколько копий базы данных для повышения доступности, производительности и отказоустойчивости. Рассмотрим настройку репликации на примере MySQL и PostgreSQL.

MySQL

Репликация в MySQL обычно настраивается для создания одного мастера и одного или нескольких слейвов (реплик).

Настройка мастера

Измените конфигурацию MySQL:
- В my.cnf (или mysqld.cnf, в зависимости от версии):
  [mysqld] server-id = 1 log_bin = /var/log/mysql/mysql-bin.log binlog_format = row
- server-id должен быть уникальным для каждого сервера в кластере. log_bin указывает путь к бинарному лог-файлу, который используется для репликации.
Перезапустите MySQL:
```
sudo systemctl restart mysql
```

Создайте пользователя для репликации:

CREATE USER 'replica_user'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'%';
FLUSH PRIVILEGES;

Получите информацию о бинарных логах:
```
SHOW MASTER STATUS;
```
- Запишите значения File и Position. Эти значения понадобятся для настройки слейва.

Настройка слейва

Измените конфигурацию MySQL на слейве:
- В my.cnf:
  [mysqld] server-id = 2
- server-id на слейве должен отличаться от server-id на мастере.
Перезапустите MySQL на слейве:
```
sudo systemctl restart mysql
```

Настройте слейв:

CHANGE MASTER TO
    MASTER_HOST='master_host',
    MASTER_USER='replica_user',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=4;
START SLAVE;

Замените master_host, MASTER_LOG_FILE и MASTER_LOG_POS на значения, полученные из команды SHOW MASTER STATUS.

Проверьте статус репликации:
```
SHOW SLAVE STATUS\G;
```
- Убедитесь, что Slave_IO_Running и Slave_SQL_Running показывают Yes, и нет ошибок в полях Last_IO_Error и Last_SQL_Error.

PostgreSQL

Репликация в PostgreSQL настраивается с помощью потока WAL (Write-Ahead Log).

Настройка мастера

Измените конфигурацию PostgreSQL:
- В postgresql.conf:
  wal_level = replica max_wal_senders = 3 wal_keep_size = 64MB
- wal_level должен быть установлен в replica для поддержки репликации. max_wal_senders указывает максимальное количество отправителей WAL. wal_keep_size определяет, сколько WAL-файлов хранить для репликации.
Настройте доступ к репликации:
- В pg_hba.conf:
  host replication all 192.168.0.0/24 md5
- Здесь 192.168.0.0/24 замените на IP-адрес вашей сети.
Перезапустите PostgreSQL:
```
sudo systemctl restart postgresql
```

Создайте пользователя для репликации:

CREATE ROLE replica_user WITH REPLICATION LOGIN PASSWORD 'password';

Настройка слейва

Создайте резервную копию данных:
```
pg_basebackup -h master_host -D /var/lib/postgresql/12/main -U replica_user -v -P
```
- Замените master_host на IP-адрес вашего мастера. /var/lib/postgresql/12/main — путь к директории данных слейва.
Создайте файл standby.signal и настройте primary_conninfo:
- В postgresql.conf на слейве:
  primary_conninfo = 'host=master_host port=5432 user=replica_user password=password'
- Создайте файл standby.signal в каталоге данных:
  touch /var/lib/postgresql/12/main/standby.signal
Перезапустите PostgreSQL на слейве:
```
sudo systemctl restart postgresql
```
Проверьте статус репликации:
```
SELECT * FROM pg_stat_replication;
```

Управление версиями схем баз данных

Управление версиями схем баз данных помогает отслеживать изменения структуры базы данных и координировать обновления между разработчиками.

Инструменты для миграций

Flyway
- Создайте папку для миграций:
  mkdir sql
- Напишите миграционный скрипт (например, V1__create_table.sql):
  CREATE TABLE employees ( id SERIAL PRIMARY KEY, name VARCHAR(100), hire_date DATE );
- Запустите миграцию:
  flyway migrate
- Конфигурация Flyway может быть указана в flyway.conf или передана через параметры командной строки.

Liquibase

Создайте файл changelog.xml:

<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog
    xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
                        http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.8.xsd">

    <changeSet id="1" author="author">
        <createTable tableName="employees">
            <column name="id" type="serial">
                <constraints primaryKey="true"/>
            </column>
            <column name="name" type="varchar(100)"/>
            <column name="hire_date" type="date"/>
        </createTable>
    </changeSet>

</databaseChangeLog>

Запустите миграцию:
```
liquibase update
```
Конфигурация Liquibase может быть указана в файле liquibase.properties или передана через параметры командной строки.

Система контроля версий

Храните миграционные скрипты в системе контроля версий (например, Git):
- Создайте репозиторий Git и добавьте миграционные скрипты:
  git init git add sql/ git commit -m "Initial migration scripts"
Используйте ветвление и слияние для управления изменениями схемы базы данных в команде:
- Создавайте ветки для каждой новой функции или изменения схемы.
- Объединяйте ветки и применяйте миграции на тестовом или стейджинг-сервере перед деплоем на продакшн.

Тестирование миграций

Тестируйте миграции на тестовых или стейджинг-окружениях, чтобы убедиться в их корректности и совместимости.
Используйте откат миграций для тестирования, чтобы обеспечить возможность возврата к предыдущему состоянию базы данных в случае проблем.

Эти методы и инструменты помогут вам эффективно управлять репликацией данных и версионированием схем баз данных, обеспечивая надежность и управляемость ваших систем.

PreviousСоздание хранимых процедур и сложных операций с данными NextИнтеграция SQL-запросов с Python и автоматическое шифрование данных

Last updated 29 days ago