0

Здравствуйте.

Имеется некое веб-приложение php+mysql. Разработка ведется в git. Нужно сделать следующее.

Нужно реализовать две версии приложения. Production и dev. С файловой частью проблем нет. Достаточно вести две ветки в git: master - выкладывается на production, ветку dev на dev версию (можно по хукам, можно по крону, либо вручную... не суть). Но вот с базой есть проблема.

Требования такие:

  1. Базы должны быть разными (то есть dev работает на одной копии БД, production на другой, боевой);
  2. Необходим перенос снимка базы в обе стороны. Т.е. нажали волшебную кнопку, копия базы с production-а встала на dev, полностью ее заменив, и в обратную сторону также;
  3. InnoDB;
  4. Обе копии должны быть размещены на одном сервере физически.

Тут у меня мыслей, к сожалению, практически нет. Если мне память не изменяет, то у mysql нету ничего похожего на

COPY `database` INTO `new_database`

Единственная мысль - делать полный дамп одной базы, чистить вторую, лить первую в очищенную. Имхо не самое оптимальное решение (база под 5 гигов, это будет очень долго), но других вариантов я не знаю.

В связи с этим вопрос: может, у вас есть какое-либо более разумное решение? Например, как-то с репликацией поиграться или еще как-нибудь. Может, тупо копирование файлов в каталоге MySQL (но у innodb с этим сложности).

В общем, нужны какие-нибудь идеи, в какую сторону мне копать(

7
  • Какой смысл в копировании базы в обе стороны?
    – KiTE
    20 сен 2014 в 15:24
  • Можно сделать скрипт, который будет делать тестовую базу. Тогда можно будет генерить любые виды записей и тестировать их у себя.
    – Deadkenny
    20 сен 2014 в 17:04
  • KiTE, не сочтите за хамство, смысл есть, иначе бы вопрос я не задавал. Причем нужно сделать именно так, как я попытался описать, другие варианты не подходят, мы уже думали над этим. Впрочем даже если в одну сторону, то это сути не меняет, других решений, кроме как делать полный дамп и его импортировать, я до сих пор не нашел. 20 сен 2014 в 17:10
  • @IntellectSys, ну так расшифруйте этот самый смысл. Возможно, для решения вашего вопроса уже есть какие-то общепринятые практики. Если вам нужно переносить данные в dev-окружение, то это одно решение, если структуру - другое.
    – KiTE
    20 сен 2014 в 17:23
  • @IntellectSys наиболее "внутреннее" решение, которое приходит в голову: 1. Получить имена всех таблиц, хоть из бд, хоть из хардкода 2. SHOW CREATE TABLE для каждой 3. Выстроить их в нужном порядке, чтобы атрибуты, к которым привязаны FK, существовали на момент объявления этих самых fk. 4. INSERT INTO ... SELECT для каждой Вряд ли это будет гораздо быстрее дампа. Альтернативно можно вести миграции, тогда пункты 1-3 отпадают.
    – etki
    20 сен 2014 в 17:30

2 ответа 2

1

Прежде чем тратить огромное количество человеко-часов на поиски решения, которое вам навязывается заказчиком - советую реалистично оценить размеры базы данных. Импорт/Экспорт любой сколько-либо значимой БД может занимать часы - это однозначно не "нажал волшебную кнопку и база за 1 секунду скопировалась", а значит вам надо включить коммуникационные навыки и объяснить заказчику что то, что он просит - технически не реализуемо.

Если же совсем совсем приспичит - делайте так:

  • Выключаем MySQL (помня, что выключение надо это сделать так, чтобы все операции из буфера записались на диск в файлы данных - а иначе скопировать базу у вас не получится)
  • Копируем файлы InnoDB из одной БД в другую
  • Включаем MySQL
1
  • Кстати, если продакшн и дев физически на одном сервере - можно доустановить на него оперативки и делать манипуляции с дампом на RAM-диске. Но это только временное решение. Про SSD молчу - на них запись 5гиг проходит достаточно шустро.
    – karevn
    8 апр 2015 в 19:50
0

Для быстрых дампов БД может подойти Percona XtraBackup из Percona Toolkit http://www.percona.com/software/percona-xtrabackup

Репликация не думаю, что будет быстрее. Слейву придется достаточно долго "догонять" мастер.

Ваш ответ

By clicking “Отправить ответ”, you agree to our terms of service and acknowledge you have read our privacy policy.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками или задайте свой вопрос.