У меня есть основная архитектура с MySql db, репликацией и резервным копированием, все работает нормально. Теперь у меня также есть сервер разработки, на котором я играю с кодом, и я хотел бы использовать данные из основной базы данных для воспроизведения, с чтением и записью. Как я могу настроить репликацию, чтобы реальные данные поступали из основной базы данных в базу данных разработки? Должен ли я реплицироваться постоянно или только один раз в день, чтобы поддерживать некоторую согласованность во время тестов на dev db? Любая идея / стратегия приветствуются.
Изменить: хорошо, чтобы уточнить, какое приложение я использую, это разработка веб-приложений с помощью Django. Идея состоит в том, чтобы протестировать некоторые новые функции на сервере разработки. Необходимость записи важна, базы данных только для чтения недостаточно для тщательного выполнения тестов. На данный момент базе данных требуется довольно разумное количество времени для сброса на другой сервер (примерно 10 минут), но оно растет.
"Правильный ответ" очень зависит от приложения, но вот несколько стратегий, которые я видел раньше.
Ежедневное резервное копирование / восстановление по запросу
Это хорошо работает, если у вас небольшой набор данных, и вам необходимо, чтобы различные разработчики использовали резервные копии для разовой обработки. Идея в основном mysqldump в целевой системе репликации и некоторых сценариях для импорта MySQL.
ETL процесс
Этот подход имеет большой смысл, если вам нужен подмножество данных или вы хотите каким-то образом замаскировать его, чтобы защитить данные от взлома. Вы можете преобразовать конфиденциальные данные в сценариях ETL и либо загрузить непосредственно в базу данных разработки, либо создать дамп, как в вышеупомянутом подходе, но вы будете знать, что он уже был очищен.
Процесс ETL может быть приятным, если вы хотите запускать его ежечасно, чтобы, скажем, извлечь последний час из производства, выполнить некоторую очистку / реорганизацию и импортировать его в "главную" базу данных разработки для экспорта в системы разработки и т. Д.
Репликация двоичного журнала
Этот метод, вероятно, не сработает для вас, поскольку вы специально хотите прочитать и написать в базу данных разработки. Иногда люди будут использовать репликацию для проведения регрессионного тестирования только для чтения, но изменение базы данных приведет к неудачной репликации и / или несогласованным данным.
это зависит от приложений, которые вы разрабатываете: простой дамп или ежедневная / еженедельная репликация помогут, если вам не нужно тестировать, как ваше приложение обрабатывает свежие данные с вашего производственного сервера, в этом случае вам понадобится постоянная репликация.
Все зависит от того, сколько данных вы хотите реплицировать. Если это довольно маленький db, вы можете делать ежедневный дамп, а затем воссоздавать db на своем сервере базы данных разработки. И вы можете читать и писать. Репликация в сценарии, когда вы хотите, чтобы запись на ведомом устройстве была довольно сложной (я не уверен, но, возможно, невозможен). Вы не можете выполнять записи на ведомом устройстве с моделью ведущий-ведомый, а в режиме ведущий-ведущий любая запись будет реплицирована на другой ведущий
Если вам нужен доступ для чтения / записи, я предлагаю вам настроить задание cron, которое просто копирует базу данных из вашего производства в вашу разработку.
плюсы: вы получаете доступ на запись
минусы: вся ваша работа будет уничтожена в следующий раз, когда вы запустите задание cron, чтобы обновить свои базы данных
если вам нужен только доступ только для чтения, я предлагаю вам настроить репликацию, используя следующие руководство: MySQL :: Справочное руководство MySQL 5.0 :: 16 Репликация
за: всегда в курсе
минусы: нельзя писать, так как в какой-то момент это может нарушить репликацию.