AWS Aurora Master / MySQL Slave - Switch Master / Slave - PullRequest
0 голосов
/ 25 октября 2019

В настоящее время у нас есть AWS Aurora Master, выполняющий репликацию на локальное ведомое устройство MySQL.

Мы хотели бы создать процесс, чтобы продвинуть подчиненное MySQL, чтобы оно стало ведущим, и понизить мастерство Aurora, чтобы оно стало ведомым.

Если бы мы использовали мастер MySQL и ведомый MySQL, процесс был бы:

  1. Запрет записи на мастер (FLUSH LOCAL TABLES WITH READ LOCK)
  2. Убедитесь, что ведомое устройство обновлено с помощью ведущего устройства
  3. Запишите файл / позицию binlog
  4. Остановите репликацию на ведомом устройстве, а затем попросите всех клиентов подключиться к этой службе вместо старого ведущего
  5. Перезапустите старый мастер (чтобы не было никаких клиентских подключений и не было выполнено ни одного запроса после выполнения блокировки чтения) и используйте CHANGE MASTER для репликации из указанного файла / позиции binlog.

Однако, с ведущим Aurora и подчиненным MySQL:

  • Шаг 1 невозможен: «FLUSH LOCAL TABLES WITH READ LOCK» запрещен даже для пользователя root.
  • Шаг 5 невозможен: остановка Aurora занимает несколько минут, и мы должны (и можем) выполнить повышение в течение минуты с мастером MySQL и подчиненным MySQL.

Мы рассмотрели возможность использования 'LOCK TABLES' для каждой отдельной таблицы, но эта блокировка будет распространяться на подчиненное устройство (не идеально!), И любые дальнейшие клиентские запросы будут выполняться, как только будет снята блокировка.

Мы сейчас рассматриваемблокирование всех новых подключений к Aurora и уничтожение любых активных подключений / запросов в полете (и разрешение нашему приложению обрабатывать эти сбои) и не выполнение каких-либо блокировок чтения.

Итак, наши вопросы:

  1. Есть ли способ запустить 'FLUSH LOCAL TABLES WITH READ LOCK' в AWS Aurora (MySQL)?
  2. Есть ли способ запустить 'LOCK TABLES' в БД MySQL, но остановитьзаблокировать от записи в binlog / репликации на ведомые устройства?
  3. Какие риски связаны с блокировкой всех новых подключений к Aurora (с обновлением SG) иубить все активные соединения Авроры (кроме тех, что сделаны rdsadmin, которые, как мы полагаем, не должны быть убиты)?
  4. Есть ли другой / лучший подход для этой акции, которую мы должны использовать?
...