Мы работаем над проектом, который использует MySQL для хранения наших данных. Мы разрабатываем и тестируем на тестовом сервере перед развертыванием на нашем производственном сервере. В процессе разработки мы вносим структурные изменения в нашу базу данных, добавляя / изменяя столбцы в таблице или добавляя дополнительные таблицы в базу данных.
Как распространить эти изменения с нашего тестового сервера на рабочий сервер, не уничтожая существующие данные?
Наш тестовый сервер работает на Mac OS X, а рабочий сервер - на Red Hat Enterprise. MySQL имеет версию 5.1.39. Спасибо за чтение и помощь.
Я думаю, это относится к stackoverflow.
Вы можете выполнить sql свои изменения в командной строке или с помощью внешнего интерфейса, такого как phpmyadmin
CREATE TABLE "table_name"
("column 1" "data_type_for_column_1",
"column 2" "data_type_for_column_2",
... )
чтобы изменить таблицу:
ALTER TABLE table_name
ADD ( column_1 column-definition,
column_2 column-definition,
...
column_n column_definition );
Возможно, это лучше подходит для StackOverflow, но я добавлю свои два цента.
Это часть процесса развертывания приложения, которую вам нужно выяснить. Вам нужно взглянуть на схему базы данных на производственном сервере и схему на тестовом сервере, а затем выяснить именно какие изменения необходимы, чтобы они совпадали. Вам нужно будет пройти таблицу за таблицей, столбец за столбцом. В зависимости от требуемых изменений возможно, что вы не могу выполнить неразрушающее развертывание. Некоторые изменения достаточно инвазивны, поэтому единственным вариантом является перенос данных (иногда это означает их экспорт и перезагрузку, возможно, с некоторыми манипуляциями с данными между ними, но, надеюсь, это означает создание таблицы замены в производственной базе данных и использование SQL для сброса содержимого. старой таблицы в нее (возможно, с некоторыми манипуляциями)).
В будущем я бы рекомендовал постоянно помнить об изменениях базы данных в процессе разработки. Всегда помните, что вам нужно будет внести эти изменения на рабочий сервер, и если вы будете отслеживать свои изменения по мере их внесения и планировать, как они будут развертываться, вы можете значительно упростить развертывание.
Как говорили другие, это вопрос о переполнении стека ... но эй, пока я здесь ...
Посмотрите, как современные среды разработки веб-приложений решают эту проблему. В Rails есть отличный способ справиться с этим, называемый «миграциями», который в основном требует, чтобы вы описывали каждое из изменений вашей схемы отдельно, затем отслеживали текущую версию схемы и применяли изменения схемы, необходимые для синхронизации базы данных с тем, что должно быть текущей реальностью. Это особенность, которая меняет жизнь.
Мы стараемся справляться с этим двумя способами.
Хорошо.
Для проектов Django мы используем Джанго Эволюция который в основном делает то же самое, что womble описывает «миграции» Rails. Это структура для управления изменениями модели и их автоматической реализации.
Не очень хорошо.
Там, где нам повезло меньше, и мы имеем дело с проектами PHP, мы оговариваем, что разработчики должны проверять свои изменения SQL вместе с соответствующими фиксациями кода в общем месте в репозитории. Изменения SQL состоят из двух вещей; чистый оператор, изменяющий базу данных, и полную схему, отражающую новое состояние базы данных. У нас есть некоторые инструменты, которые упрощают процесс сбора этой информации и преобразования ее в приемлемые форматы. Во время развертывания кода файл SQL, содержащий операторы изменения, выполняется в базе данных.