Yandex Cloud
  • Сервисы
  • Решения
  • Почему Yandex Cloud
  • Сообщество
  • Тарифы
  • Документация
  • Связаться с нами
Подключиться
Language / Region
Проект Яндекса
© 2023 ООО «Яндекс.Облако»
Практические руководства
  • Веб-сервис
    • Все руководства
    • Статический сайт в Object Storage
    • Сайт на LAMP- или LEMP-стеке
    • Отказоустойчивый сайт с балансировкой нагрузки с помощью Network Load Balancer
    • Отказоустойчивый сайт с балансировкой нагрузки с помощью Application Load Balancer
    • Сайт на базе Joomla с БД PostgreSQL
    • Создание сайта на WordPress
    • Сайт на WordPress с БД MySQL
    • Перенос WordPress сайта с хостинга в Yandex Cloud
    • Сайт на базе 1С-Битрикс
    • Организация виртуального хостинга
    • Создание балансировщика с защитой от DDoS
    • Публикация обновлений для игр с помощью Cloud CDN
    • Интеграция L7-балансировщика с Cloud CDN и Object Storage
    • Сине-зеленое и канареечное развертывание версий сервиса
    • Терминирование TLS-соединений
  • Интернет-магазины
    • Все руководства
    • Интернет-магазин на 1С-Битрикс
    • Интернет-магазин на OpenCart
  • Архив данных
    • Все руководства
    • Однонодовый файловый сервер
    • Настройка SFTP-сервера на Centos 7
    • Резервное копирование в Object Storage через Acronis
    • Резервное копирование в Object Storage с помощью CloudBerry Desktop Backup
    • Резервное копирование в Object Storage через Duplicati
    • Резервное копирование в Object Storage с помощью Bacula
    • Резервное копирование в Object Storage с помощью Veritas Backup Exec
    • Распознавание архива изображений в Vision
  • Тестовая среда
    • Все руководства
    • Тестирование приложений с помощью GitLab
    • Создание тестовых ВМ через GitLab CI
    • Высокопроизводительные вычисления на прерываемых ВМ
    • Эмуляция множества IoT-устройств
    • Нагрузочное тестирование gRPC-сервиса
    • Развертывание и нагрузочное тестирование gRPC-сервиса с масштабированием
    • HTTPS-тест с постоянной нагрузкой с помощью Phantom
    • HTTPS-тест со ступенчатой нагрузкой с помощью Pandora
    • Нагрузочное тестирование с нескольких агентов
  • Управление инфраструктурой
    • Все руководства
    • Начало работы с Terraform
    • Загрузка состояний Terraform в Object Storage
    • Начало работы с Packer
    • Сборка образа ВМ с набором инфраструктурных инструментов с помощью Packer
    • Автоматизация сборки образов с помощью Jenkins и Packer
    • Непрерывное развертывание контейнеризованных приложений с помощью GitLab
    • Создание кластера Linux-серверов «1С:Предприятия» с кластером Managed Service for PostgreSQL
    • Миграция в Yandex Cloud с помощью Hystax Acura
    • Защита от сбоев с помощью Hystax Acura
    • Настройка синхронизации часов с помощью NTP
    • Работа с группой ВМ с автомасштабированием
    • Масштабирование группы ВМ по расписанию
    • Автомасштабирование группы ВМ для обработки сообщений из очереди Message Queue
    • Обновление группы ВМ под нагрузкой
    • Передача логов с ВМ в Cloud Logging
    • Резервное копирование ВМ с помощью Hystax Acura Backup
    • Настройка отказоустойчивой архитектуры в Yandex Cloud
    • Создание SAP-программы в Yandex Cloud
    • Настройка локального кеширующего DNS-резолвера
    • Миграция DNS-зон из Яндекс 360 в Cloud DNS
    • Интеграция Cloud DNS и корпоративного сервиса DNS
    • Создание веб-хука резолвера ACME для ответов на DNS01-проверки
    • Запись логов балансировщика в PostgreSQL
    • Создание триггера для бюджетов, который вызывает функцию для остановки ВМ
  • Построение Data Platform
    • Все руководства
    • Миграция БД из стороннего кластера Apache Kafka® в Managed Service for Apache Kafka®
    • Поставка данных из Managed Service for MySQL в Managed Service for Apache Kafka® с помощью Data Transfer
    • Поставка данных из Managed Service for PostgreSQL в Managed Service for Apache Kafka® с помощью Data Transfer
    • Поставка данных из Managed Service for Apache Kafka® в Managed Service for ClickHouse с помощью Data Transfer
    • Перенос данных между кластерами Managed Service for Apache Kafka® с помощью Data Transfer
    • Поставка данных из Managed Service for Apache Kafka® в Managed Service for YDB с помощью Data Transfer
    • Поставка данных из Managed Service for MySQL в Managed Service for Apache Kafka® с помощью Debezium
    • Поставка данных из Managed Service for PostgreSQL в Managed Service for Apache Kafka® с помощью Debezium
    • Настройка Kafka Connect для работы с кластером Managed Service for Apache Kafka®
    • Управление схемами данных в Managed Service for Apache Kafka®
    • Использование Managed Schema Registry с Managed Service for Apache Kafka®
    • Использование Confluent Schema Registry с Managed Service for Apache Kafka®
    • Миграция базы данных из MySQL в ClickHouse с помощью Data Transfer
    • Асинхронная репликация данных из PostgreSQL в ClickHouse
    • Обмен данными между Managed Service for ClickHouse и Data Proc
    • Настройка Managed Service for ClickHouse для Graphite
    • Получение данных из Managed Service for Apache Kafka® в Managed Service for ClickHouse
    • Поставка данных из Managed Service for Apache Kafka® в Managed Service for ClickHouse с помощью Data Transfer
    • Получение данных из RabbitMQ в Managed Service for ClickHouse
    • Сохранение потока данных Data Streams в Managed Service for ClickHouse
    • Использование гибридного хранилища в Managed Service for ClickHouse
    • Шардирование таблиц Managed Service for ClickHouse
    • Настройка Cloud DNS для доступа к кластерам управляемых баз данных из других облачных сетей
    • Настройка Cloud DNS для доступа к кластеру Managed Service for ClickHouse из других облачных сетей
    • Обмен данными между Managed Service for ClickHouse и Data Proc
    • Импорт данных из Managed Service for MySQL в Data Proc с помощью Sqoop
    • Импорт данных из Managed Service for PostgreSQL в Data Proc с помощью Sqoop
    • Использование скриптов инициализации для настройки GeeseFS в Data Proc
    • Миграция данных из стороннего кластера Elasticsearch в Managed Service for Elasticsearch с помощью Reindex API
    • Миграция коллекций из стороннего кластера MongoDB в Managed Service for MongoDB
    • Миграция данных в Managed Service for MongoDB
    • Шардирование коллекций MongoDB
    • Анализ производительности и оптимизация MongoDB
    • Миграция БД из стороннего кластера MySQL в кластер Managed Service for MySQL
    • Анализ производительности и оптимизация Managed Service for MySQL
    • Синхронизация данных из стороннего кластера MySQL в Managed Service for MySQL с помощью Data Transfer
    • Миграция БД из Managed Service for MySQL в сторонний кластер MySQL
    • Миграция БД из Managed Service for MySQL в Object Storage с помощью Data Transfer
    • Импорт данных из Managed Service for MySQL в Data Proc с помощью Sqoop
    • Поставка данных из Managed Service for MySQL в Managed Service for Apache Kafka® с помощью Data Transfer
    • Поставка данных из Managed Service for MySQL в Managed Service for Apache Kafka® с помощью Debezium
    • Миграция БД из Managed Service for MySQL в Managed Service for YDB с помощью Data Transfer
    • Создание кластера PostgreSQL для «1С:Предприятия»
    • Анализ производительности и оптимизация Managed Service for PostgreSQL
    • Миграция БД из Managed Service for PostgreSQL
    • Миграция БД из стороннего кластера PostgreSQL в Managed Service for PostgreSQL
    • Асинхронная репликация данных из PostgreSQL в ClickHouse
    • Поставка данных из Managed Service for PostgreSQL в Managed Service for Apache Kafka® с помощью Data Transfer
    • Поставка данных из Managed Service for PostgreSQL в Managed Service for Apache Kafka® с помощью Debezium
    • Импорт данных из Managed Service for PostgreSQL в Data Proc с помощью Sqoop
    • Поставка данных из Managed Service for PostgreSQL в Managed Service for YDB с помощью Data Transfer
    • Миграция БД из Managed Service for PostgreSQL в Object Storage
    • Миграция БД из Greenplum® в ClickHouse
    • Миграция БД из Greenplum® в PostgreSQL
    • Миграция БД из стороннего кластера Redis в Managed Service for Redis
    • Использование кластера Managed Service for Redis в качестве хранилища сессий PHP
  • Продукты Microsoft в Yandex Cloud
    • Все руководства
    • Развертывание Active Directory
    • Развертывание Microsoft Exchange
    • Развертывание Remote Desktop Services
    • Развертывание группы доступности Always On с внутренним сетевым балансировщиком
    • Развертывание Remote Desktop Gateway
  • Сетевая инфраструктура
    • Все руководства
    • Архитектура и защита базового интернет-сервиса
    • Настройки DHCP для работы с корпоративным DNS-сервером
    • Маршрутизация с помощью NAT-инстанса
    • Создание туннеля IPSec VPN
    • Установка виртуального роутера Cisco CSR 1000v
    • Установка виртуального роутера Mikrotik CHR
    • Соединение с облачной сетью при помощи OpenVPN
    • Создание и настройка шлюза UserGate в режиме прокси-сервера
    • Создание и настройка шлюза UserGate в режиме межсетевого экрана
    • Настройка сети для Data Proc
  • Визуализация и анализ данных
    • Все руководства
    • Визуализация данных из файла
    • Создание и публикация диаграммы с картой Москвы из CSV-файла
    • Анализ продаж сети магазинов из БД ClickHouse
    • Анализ открытых данных ДТП на дорогах России
    • Анализ продаж и локаций пиццерий на данных из БД ClickHouse и Cloud Marketplace
    • Веб-аналитика с подключением к Яндекс Метрике
    • Веб-аналитика с расчетом воронок и когорт на данных Яндекс Метрики
    • Аналитика мобильного приложения на данных AppMetrica
    • Анализ статистики подкастов Яндекс Музыки (для авторов подкастов)
    • Визуализация данных с помощью QL-чарта
    • Анализ customer journey мобильного приложения на данных AppMetrica
    • Анализ логов Object Storage при помощи DataLens
  • Интернет вещей
    • Руководства по работе с интернетом вещей
    • Мониторинг состояния географически распределенных устройств
    • Мониторинг показаний датчиков и уведомления о событиях
  • Бессерверные технологии
    • Сокращатель ссылок
    • Ввод данных в системы хранения
    • Хранение журналов работы приложения
    • Развертывание веб-приложения с использованием Java Servlet API
    • Разработка Slack-бота
    • Разработка Telegram-бота
    • Разработка пользовательской интеграции в API Gateway
    • Разработка CRUD API для сервиса фильмов
    • Разработка навыка Алисы и сайта с авторизацией
  1. Построение Data Platform
  2. Миграция БД из Managed Service for MySQL в сторонний кластер MySQL

Миграция базы данных из Yandex Managed Service for MySQL в сторонний кластер MySQL

Статья создана
Yandex Cloud
  • Перед началом работы
  • Перенос данных с использованием сервиса Yandex Data Transfer
  • Перенос данных с помощью внешней репликации
    • Перенесите логический дамп базы данных
    • Настройте пользователя в кластере-источнике для управления репликацией
    • Запустите репликацию в кластере-приемнике
    • Отслеживайте процесс миграции
    • Закончите миграцию

Примечание

Миграция данных из стороннего кластера MySQL описана в статье Миграция базы данных из стороннего кластера MySQL.

Чтобы перенести базу данных, развернутую в кластере Managed Service for MySQL, на сторонний кластер MySQL:

  1. Перенесите данные.
  2. Закройте старую базу данных на запись.
  3. Переведите нагрузку на сторонний кластер.

Поддерживается миграция между разными версиями: например, можно перенести базы из MySQL версии 5.7 в версию 8. При этом мажорная версия MySQL на стороннем кластере должна быть не ниже версии на кластере Managed Service for MySQL.

Перенести данные из кластера-источника Managed Service for MySQL в сторонний кластер-приемник MySQL можно двумя способами:

  • Перенос данных с использованием сервиса Yandex Data Transfer.

    Этот способ позволяет перенести базу целиком без остановки обслуживания пользователей.

    Подробнее см. в разделе Какие задачи решает сервис Yandex Data Transfer.

  • Перенос данных с помощью внешней репликации.

    Внешняя репликация позволяет мигрировать базы данных между кластерами MySQL, используя встроенные средства СУБД.

    Используйте этот способ только в том случае, если перенос данных с помощью Yandex Data Transfer по каким-либо причинам невозможен.

Перед началом работы

Подготовьте кластер-приемник:

  • Создайте базу данных MySQL любой подходящей конфигурации.
  • Убедитесь, что к хостам кластера-приемника можно подключиться из интернета.

Дополнительно для переноса с помощью внешней репликации MySQL:

  • Убедитесь, что все хосты кластера-источника доступны по публичному IP-адресу, чтобы кластер-приемник мог подключаться к источнику. Для этого:
    • Добавьте хосты с публичными IP-адресами.
    • Удалите хосты без публичных IP-адресов.
  • Установите на хосты кластера-приемника серверные SSL-сертификаты Managed Service for MySQL. Они требуются для подключения к публично доступному кластеру-источнику.
  • При необходимости настройте межсетевой экран (firewall) и группы безопасности, чтобы можно было подключаться из кластера-приемника к кластеру-источнику, а также к каждому кластеру в отдельности (например, с помощью утилиты mysql).
  • Убедитесь, что с хостов кластера-приемника можно подключиться к хостам кластера-источника.
  • Убедитесь, что можно подключиться к кластеру-источнику и к кластеру-приемнику с SSL.

Перенос данных с использованием сервиса Yandex Data Transfer

  1. Подготовьте базу данных кластера-источника.

  2. Подготовьте базу данных кластера-приемника.

  3. Создайте эндпоинты и трансфер:

    Вручную
    С помощью Terraform
    1. Создайте эндпоинт для источника:

      • Тип базы данных — MySQL.

      • Настройки подключения — Кластер MDB.

        Укажите идентификатор кластера-источника.

    2. Создайте эндпоинт для приемника:

      • Тип базы данных — MySQL.

      • Настройки подключения — Пользовательская инсталляция.

        Укажите параметры подключения к кластеру-приемнику.

    3. Создайте трансфер типа Копирование и репликация, использующий созданные эндпоинты.

    4. Активируйте трансфер.

    1. Если у вас еще нет Terraform, установите его.

    2. Скачайте файл с настройками провайдера. Поместите его в отдельную рабочую директорию и укажите значения параметров.

    3. Скачайте в ту же рабочую директорию файл конфигурации трансфера и эндпоинтов data-transfer-mmy-mysql.tf.

    4. Укажите в файле конфигурации:

      • параметры эндпоинта-источника;
      • параметры эндпоинта-приемника.
    5. Выполните команду terraform init в директории с конфигурационными файлами. Эта команда инициализирует провайдер, указанный в конфигурационных файлах, и позволяет работать с ресурсами и источниками данных провайдера.

    6. Проверьте корректность файлов конфигурации Terraform с помощью команды:

      terraform validate
      

      Если в файлах конфигурации есть ошибки, Terraform на них укажет.

    7. Создайте необходимую инфраструктуру:

      1. Выполните команду для просмотра планируемых изменений:

        terraform plan
        

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

      2. Если вас устраивают планируемые изменения, внесите их:

        1. Выполните команду:

          terraform apply
          
        2. Подтвердите изменение ресурсов.

        3. Дождитесь завершения операции.

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

      Трансфер активируется автоматически после создания.

    Важно

    Избегайте любых изменений в схеме данных на кластере-источнике и кластере-приемнике во время работы трансфера. Подробнее см. в разделе Работа с базами данных во время трансфера.

  4. Дождитесь перехода трансфера в статус Реплицируется.

  5. Переведите кластер-источник в режим только чтение и переключите нагрузку на кластер-приемник.

  6. На странице мониторинга трансфера дождитесь снижения до нуля характеристики Maximum lag on delivery, [s]. Это значит, что в кластер-приемник перенесены все изменения, произошедшие в кластере-источнике после завершения копирования данных.

  7. Деактивируйте трансфер и дождитесь его перехода в статус Остановлен.

    Подробнее о статусах трансфера см. в разделе Жизненный цикл трансфера.

  8. Удалите созданные эндпоинты и трансфер:

    Вручную
    С помощью Terraform

    Если вы создали эндпоинты и трансфер вручную, то:

    1. Удалите остановленный трансфер.
    2. Удалите эндпоинты для источника и приемника.

    Если вы создали эндпоинты и трансфер с помощью Terraform, то:

    1. В командной строке перейдите в каталог, в котором расположен актуальный конфигурационный файл Terraform с планом инфраструктуры.

    2. Удалите конфигурационный файл data-transfer-mmy-mysql.tf.

    3. Проверьте корректность файлов конфигурации Terraform с помощью команды:

      terraform validate
      

      Если в файлах конфигурации есть ошибки, Terraform на них укажет.

    4. Подтвердите изменение ресурсов.

      1. Выполните команду для просмотра планируемых изменений:

        terraform plan
        

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

      2. Если вас устраивают планируемые изменения, внесите их:

        1. Выполните команду:

          terraform apply
          
        2. Подтвердите изменение ресурсов.

        3. Дождитесь завершения операции.

      Все ресурсы, которые были описаны в конфигурационном файле data-transfer-mmy-mysql.tf, будут удалены.

Перенос данных с помощью внешней репликации

  1. Перенесите логический дамп базы данных.
  2. Настройте пользователя в кластере-источнике для управления репликацией.
  3. Запустите репликацию в кластере-приемнике.
  4. Отслеживайте процесс миграции до его завершения.
  5. Закончите миграцию.

Перенесите логический дамп базы данных

Логический дамп — файл с набором команд, последовательное выполнение которых позволяет восстановить состояние базы данных. Он создается с помощью утилиты mysqldump. Чтобы обеспечить полноту логического дампа, перед его созданием приостановите запись в базу данных.

  1. Запросите текущую позицию бинарного лога для консистентности восстановления логического дампа:

    SHOW MASTER STATUS;
    
    +-------------------------+----------+--------------+------------------+-----------------------------+
    | File                    | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set           |
    +-------------------------+----------+--------------+------------------+-----------------------------+
    | mysql-bin-log-...000224 |  2058567 |              |                  | d827098b-...00b86:1-1575866 |
    +-------------------------+----------+--------------+------------------+-----------------------------+
    1 row in set (0.00 sec)
    

    Запишите значения File и Position. Они понадобятся при запуске репликации.

  2. Создайте дамп базы кластера-источника:

    mysqldump \
        --databases=<имя базы данных> \
        --routines \
        --host=<FQDN хоста-мастера> \
        --ssl-ca=<путь к SSL-сертификату> \
        --user=<имя пользователя-владельца БД> > <файл дампа>
    

    Совет

    Используйте особый FQDN, который всегда указывает на текущий хост-мастер в кластерах Managed Service for MySQL.

  3. Восстановите базу данных из дампа в кластере-приемнике:

    Подключение с SSL
    Подключение без SSL
    mysql --host=<FQDN хоста-мастера> \
          --user=<имя пользователя> \
          --password \
          --port=3306 \
          --ssl-ca=<путь к файлу сертификата> \
          --ssl-mode=VERIFY_IDENTITY \
          --line-numbers \
          <имя базы данных> < <файл дампа>
    
    mysql --host=<FQDN хоста-мастера> \
          --user=<имя пользователя> \
          --password \
          --port=3306 \
          --line-numbers \
          <имя базы данных> < <файл дампа>
    
  4. Создайте в кластере-приемнике пользователя с полными правами на доступ к переносимой базе данных:

    CREATE USER '<имя пользователя>'@'%' IDENTIFIED BY '<пароль>';
    GRANT ALL PRIVILEGES ON <имя базы>.* TO '<имя пользователя>'@'%';
    

Настройте пользователя в кластере-источнике для управления репликацией

MySQL использует модель мастер-реплика при выполнении репликации: кластер-приемник копирует изменения бинарного лога кластера-источника в свой лог, который называется логом ретрансляции (relay log). Хост-реплика воспроизводит изменения из лога ретрансляции, применяя их к собственным данным.

Чтобы получать изменения бинарного лога и управлять потоком репликации в кластере-источнике:

  1. Создайте пользователя.
  2. Назначьте роль ALL_PRIVILEGES этому пользователю на базу кластера-источника.
  3. Назначьте глобальные привилегии REPLICATION CLIENT и REPLICATION SLAVE этому пользователю.

Кластер-приемник будет подключаться к кластеру-источнику от имени этого пользователя.

Запустите репликацию в кластере-приемнике

  1. Измените файл конфигурации кластера-приемника /etc/mysql/my.cnf для начала репликации:

    [mysqld]
    ...
    log_bin = mysql-bin
    server_id = 2
    relay-log = /var/lib/mysql/mysql-relay-bin
    relay-log-index = /var/lib/mysql/mysql-relay-bin.index
    
    gtid-mode = on
    enforce-gtid-consistency = on
    

    Где:

    • log_bin — имя бинарного лога в кластере-приемнике.
    • server_id — идентификатор кластера-приемника. Значение по умолчанию — 1, но для репликации необходимо, чтобы значения идентификаторов кластера-источника и кластера-приемника различались.
    • relay-log — путь к логу ретрансляции.
    • relay-log-index — путь к индексу лога ретрансляции.

    Также для репликации включите настройки gtid-mode и enforce-gtid-consistency. В кластерах Managed Service for MySQL они включены всегда.

  2. Перезапустите сервис mysql:

    sudo systemctl restart mysql
    
  3. Подключитесь к кластеру-приемнику от имени пользователя с полными правами на доступ к переносимой базе данных.

  4. Включите репликацию базы данных и отключите репликацию служебных баз данных (по умолчанию они реплицируются):

    CHANGE REPLICATION FILTER
        REPLICATE_DO_DB=(
            <имя базы кластера-приемника>
        ),
        REPLICATE_IGNORE_DB=(
            sys,
            mysql,
            performance_schema,
            information_schema
        );
    
  5. Чтобы назначить мастера для кластера-приемника, укажите параметры хоста-мастера кластера-источника:

    Совет

    Используйте особый FQDN, который всегда указывает на текущий хост-мастер в кластерах Managed Service for MySQL.

    CHANGE MASTER TO
          MASTER_HOST = '<FQDN хоста-мастера>',
          MASTER_USER = '<пользователь для репликации>',
          MASTER_PASSWORD = '<пароль пользователя>',
          MASTER_LOG_FILE = '<значение File из запроса позиции бинарного лога>',
          MASTER_LOG_POS = <значение Position из запроса позиции бинарного лога>,
          MASTER_SSL_CA = '<путь к SSL-сертификату>',
          MASTER_SSL_VERIFY_SERVER_CERT = 0,
          MASTER_SSL = 1;
    
  6. Запустите воспроизведение лога ретрансляции:

    START SLAVE;
    

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

Отслеживайте процесс миграции

Используйте команду, которая показывает статус репликации:

SHOW SLAVE STATUS\G
*************************** 1. row ***************************
           Slave_IO_State: Waiting for master to send event
              Master_Host: rc1a-hxk9audl2lsi53hc.mdb.yandexcloud.net
              Master_User: replica-my
              Master_Port: 3306
            Connect_Retry: 60
          Master_Log_File: mysql-bin-log-rc1a-hxk9audl2lsi53hc-mdb-yandexcloud-net.000225
      Read_Master_Log_Pos: 1702815
           Relay_Log_File: 6b6d647a39b6-relay-bin.000084
            Relay_Log_Pos: 409
            ...

Статус репликации показывают значения полей:

  • Slave_IO_State, Slave_SQL_Running_State — состояние I/O потока бинарного лога и потока лога ретрансляции. При успешной репликации активны оба потока.
  • Read_Master_Log_Pos — последняя позиция, прочитанная из лога хоста-мастера.
  • Seconds_Behind_Master — отставание реплики от мастера (в секундах).
  • Last_IO_Error, Last_SQL_Error — ошибки репликации.

Подробнее о статусе репликации см. в документации MySQL.

Закончите миграцию

  1. Снимите нагрузку с кластера-источника и убедитесь, что приложение не пишет данные в базу кластера-источника. Для этого можно изменить пользовательскую настройку кластера-источника MAX_UPDATES_PER_HOUR на 1.

  2. Дождитесь снижения до нуля характеристики Seconds_Behind_Master. Это значит, что на кластер-приемник перенесены все изменения, произошедшие в кластере-источнике после создания логического дампа.

  3. Остановите репликацию в кластере-приемнике:

    STOP SLAVE;
    
  4. Переключите нагрузку на кластер-приемник.

  5. Удалите пользователя для управления репликацией в кластере-источнике.

  6. Удалите пользователя с полными правами на доступ к переносимой базе в кластере-приемнике, если он больше не нужен.

Была ли статья полезна?

Language / Region
Проект Яндекса
© 2023 ООО «Яндекс.Облако»
В этой статье:
  • Перед началом работы
  • Перенос данных с использованием сервиса Yandex Data Transfer
  • Перенос данных с помощью внешней репликации
  • Перенесите логический дамп базы данных
  • Настройте пользователя в кластере-источнике для управления репликацией
  • Запустите репликацию в кластере-приемнике
  • Отслеживайте процесс миграции
  • Закончите миграцию