Масштабные изменения MySQL для активных сайтов

Question

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

Я планирую сделать все на моем сервере разработки, экспортировать новую структуру MySQL для БД и импортировать ее на клиентский сервер.

В основном мне нужно знать, что выполнение импорта только структуры не будет перезаписывать / удалять существующие данные.Я не изменяю тип данных или длину поля.

Answer 1

По моему опыту, когда вы экспортируете базу данных (например, через phpMyAdmin), часть созданного сценария SQL включает в себя «DROP TABLE IF EXISTS 'table_name';» перед выполнением "CREATE TABLE 'table_name' ...;" построить новую таблицу.

Я думаю, это , а не , что вы хотите сделать! Конечно, используйте систему dev, чтобы изменить структуру, чтобы все исправить, но затем найдите процедуру синхронизации базы данных, в которой вы можете указать старую структуру, новую структуру и программное обеспечение создаст соответствующую таблицу ALTER TABLE «имя_таблицы» ...;» скрипты для внесения необходимых изменений.

Затем вы должны проверить эти файлы изменений перед выполнением их в действующей базе данных и, конечно, BACKUP действующей базе данных и убедиться, что вы можете полностью восстановить из резервной копии. перед началом каких-либо изменений!

Answer 2

Я бы порекомендовал подготовить сценарий sql для каждого изменения, которое вы делаете на сервере разработки, чтобы вы могли воспроизвести его при разработке.Вы не должны доходить до того, что вам нужно вычислять различия между структурами базы данных

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

Протестируйте окончательную версию на «промежуточном» сервере MySQL.Сделайте копию своего рабочего сервера на другом компьютере и протестируйте свой сценарий, чтобы убедиться, что все в порядке.

Конечно, предварительное резервное копирование базы данных является обязательным.

Answer 3

Мне приходилось делать это много, и всегда так:

1. Сделайте резервную копию действующей базы данных с данными.
2. Сделайте резервную копию только схемы действующей базы данных.
3. Рассчитать разницу между старой (действующей) схемой и новой (разрабатываемой) схемой.
4. Создайте все операторы DDL «ALTER TABLE ...», необходимые для обновления старой схемы до новой. Помните, что если вы переименуете поле, вы, вероятно, не сможете просто переименовать его - вам нужно будет создать новое поле, скопировать данные из старого поля и затем удалить старое поле.
5. Если вы изменили отношения между таблицами, вам, вероятно, потребуется сначала удалить индексы и отношения внешних ключей, а затем добавить их обратно.
6. Вам нужно будет заполнить все новые поля на основе их значений по умолчанию, если таковые имеются.
7. После того как все части работают, вам нужно объединить их в один большой скрипт, а затем запустить его на копии действующей базы данных.
8. Создайте дамп схемы и сравните ее с желаемой новой схемой - если они не совпадают, вернитесь к шагу 3 и повторите.
9. Сбросьте данные и сравните их с ожидаемыми изменениями - снова, если они не совпадают, вернитесь к шагу 3 и повторите.

В ходе этого процесса вы узнаете намного больше о SQL DDL / DML, чем вы когда-либо думали. (Для одного проекта, где мы переходили с естественных ключей на ключи UUID для таблиц более 50, я закончил писать программы для генерации всего DDL / DML.)

Удачи и частых резервных копий.