Всем привет!
Прошу подсказать - как лучше поступить:
Жил-был BGB версии 5.0
В один прекрасный день решили дотянуть его до v5.1
Сказано-сделано:
-взяли дежурный комп
-зеркально слили туда каталоги /var/lib/mysql/*, /usr/local/BG*
-поставили яву, подняли queue-server, накатили по readme апдейты, подправили конфиги ява-процессов и модулей, запустили...
-Наигравшись всласть решили что можно вводить в продакшн. Но: Боевая база v5.0 и "игрушечная" v5.1 за это время жутко рассинхронизировались!
Конечно можно снять mysql-дамп с боевой и и скормить в 5.1, но вот наличие серьёзного patch.sql в update5.1.zip наводит на мысль что сей номер - дохлый.
А наличие конструкций типа "create table if not exist", alter table в init-ах модулей ipn, dialup, voip , mps, npay,[,,] ещё более укрепляет мысль в различии структур таблиц мускуля в разных версиях биллинга.
На горизонте призрачно маячут 2 способа решения проблеммы:
1. манипулируя mysqldump --no-data над базами старой и новой версиq ( или show create table ) получить diff , а потом и patch.sql с учётом всех модулей и плагинов. Потом останется в тупую скопировать базу старой версии в новый биллинг и натравить на неё свежеизготовленный patch.sql . Но это потянет за собой кучу мусора в виде подневных-помесячных-погодовых таблиц, которые уже не нужны.
2.Скопипасить все sql - статементы из всех init-ов модулей и плагинов в patch.sql ( из комплекта update5.1.zip) , возможно подкорректировать получившийся Big_patch.sql. И опять-же пройтись им по свеже-скопированной базе старой версии в каталог новой версии.
Если у кого есть опыт сиих манипуляций - подскажите, что я не учитываю в этих методиках, может есть более красивое решение ?
З.Ы.
я понимаю что конфиги сервера, модулей и насов тоже хранятся в базе, но их скопипастить из архивных копий - дело 5-и минут, в отличие от наработки и прочего...)