Как мне автоматизировать репликацию рабочей базы данных MySQL на сервер разработки чтения/записи для тестирования, а также предварительно очистить данные?

Я знаю, что здесь много переменных, и они сильно зависят от приложений в среде, а также от потребностей организации. Я сначала прочитал этот пост, так как вопрос был похожим.[https://serverfault.com/questions/380701/replication-main-mysql-db-to-a-development-server-to-play-with-real-data][1]

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

  • У нас есть автономный сервер, на котором размещена онлайн-система управления обучением.
  • У LMS тысячи пользователей, и запись в ее базу данных осуществляется довольно регулярно.
  • Желание состоит в том, чтобы сделать «снимок» базы данных и реплицировать его на сервер разработки для тестирования, новых сборок и т. д.
  • Снимок должен быть относительно близок (максимум в течение нескольких дней) к реальным данным из-за динамического характера базы данных.
  • Сервер разработки должен быть доступен для чтения/записи, но никогда не затрагивать сервер prod.
  • Данные в базе данных будут иметь идентификационную информацию, и их необходимо будет очистить, прежде чем команда разработчиков сможет получить к ним доступ.

Я думаю, что общие шаги должны быть следующими:

  1. Автоматизируйте mysqldump по какому-то расписанию от продукта к разработчику
  2. Запустите скрипт на разработчике для очистки/анонимизации данных.
  3. Автоматизируйте восстановление чистых данных по расписанию в dev.

Основываясь на этих требованиях, упускаю ли я что-нибудь очевидное, что может повлиять на данные на сервере или на нагрузку/ресурсы на сервере?

Источник

2 ответа

План А

Рассмотрим следующую настройку:

  • Настройка первичной реплики (обычная репликация)
  • Реплике требуется дополнительное дисковое пространство. (Рекомендуется увеличить размер набора данных в 3 раза.)
  • В реплике уже настроен LVM.
  • На реплике сделайте снимок — это займет около минуты, независимо от размера набора данных.
  • Анонимизируйте данные (и т. д.) в снимке.
  • Используйте снимок для тестирования.
  • Снимок отделен от реплики, которая продолжает получать записи.
  • LVM зависит от «Копировать при записи», поэтому снимок поначалу практически не занимает дискового пространства, но со временем увеличивается в размере. Закончив тестирование (или настало время сделать новый снимок), удалите его, чтобы освободить место на диске.

План A2 . При таком использовании более одной реплики можно обрабатывать несколько настроек разработки/тестирования/сборки.

План B

  • Настройте кластер Galera на трех «узлах». Все три будут иметь одинаковые данные.
  • Если вы хотите протестировать, выделите один узел из кластера, чтобы использовать его для разработки.
  • Когда тестирование закончено, но оно возвращается в кластер; он автоматически повторит синхронизацию. (Дайте ему время для повторной синхронизации, прежде чем снова использовать его для разработки.)
  • Обратите внимание: если анонимизация данных слишком интенсивна, повторная синхронизация займет много времени.

Plan B2 -- План Б, но с 4 узлами; это обеспечивает полное автоматическое переключение при сбое, даже если один узел используется разработчиком.

План Б3 — План Б, но используйте «garbd», чтобы избежать необходимости в полном третьем узле. (В этом плане аварийное переключение теряется, если у вас нет 4 узлов.)

План Б4 . Имея 5 узлов (один из которых может быть гарбдом), вы можете пинг-понг двух узлов для использования разработчиками. Один активно анонимизирует, другой активно используется. (Я бы не стал выходить за рамки 5 узлов по разным причинам.)

Примечания

  • Совет здесь является «общим», а не конкретным для LMS.
  • Загрузка сервера разработки занимает всего несколько минут (плюс анонимизация).
  • Реплики (обычные или Galera) предоставляют удобные методы создания резервных копий.
Источник

Разработчики, которые, возможно, работают с конфиденциальными данными PII, могут значительно усложнить ситуацию. Спросите своего специалиста по соответствию о том, какие риски это создает и какие средства контроля и обучения должны быть предусмотрены, чтобы обеспечить разработчикам тот же уровень уважения к данным, что и операционному персоналу.

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

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

Если возникнет необходимость преобразовать копию продукции в непроизводственную среду, на мой взгляд, это должна быть отдельная среда поддержки или сцены, и разработчики не должны иметь к ней доступа, а только вспомогательный персонал. Минимизирует влияние чего-либо при тестировании на то, что пользователи заметят. Полная копия непроизводственной среды может быть недоступна в течение длительного периода времени, поскольку перезапись всех PII занимает много времени.

Источник
Другие вопросы по тегам