Транзакционный рабочий процесс DDL для MySQL

Я был немного удивлен, обнаружив, что операторы DDL (alter table, create index и т. д.) неявно фиксируют текущую транзакцию в MySQL. Начиная с MS SQL Server, возможность локального изменения базы данных в транзакции (которая затем откатывается) была важной частью моего рабочего процесса. Для непрерывной интеграции использовался откат, если миграция по каким-то причинам давала сбои, чтобы мы хотя бы не оставили базу в полумигрированном состоянии.

Как люди решают эти две проблемы при использовании MySQL с миграциями и непрерывной интеграцией?


mysql continuous-integration transactions ddl rollback
person sennett    schedule 28.01.2015    source источник
comment
Перекрестная публикация в DBA: dba.stackexchange.com/q/90794/18273   -  person sennett    schedule 02.02.2015
comment
Добро пожаловать в чудесный мир MySQL :)   -  person David Soussan    schedule 16.03.2015
comment
Вы уверены, что команда SQL Server DDL не фиксирует транзакцию? потому что в команде Oracle DDL также фиксируется транзакция.   -  person Mostafa Vatanpour    schedule 30.05.2016
comment
ВВУУУУУУУУУУ. Oracle/MySQL отстой, если это правда. Невероятный. И да, мы уверены, что операторы DDL участвуют в текущей транзакции в Microsoft SQL Server и не автоматически фиксируют транзакцию после каждого оператора (вау), как это делает Oracle. Как вы думаете, как EntityFramework может моделировать миграции кода, которые можно применять и откатывать транзакционно, включая в них множество операторов DDL. Это делает MySQL принципиально несовместимым с чем-то вроде EntityFramework. Почему они вообще пытаются интегрироваться с ним?   -  person Triynko    schedule 28.03.2019

Ответы (2)


arrow_upward
3
arrow_downward

Операторы DDL вызывают неявную фиксацию, и вы ничего не можете с этим поделать. Невозможно остановить это поведение.

Какие операторы DDL имеют такое поведение, которое со временем меняется, поэтому вам необходимо проверить свою версию.

5.1 http://dev.mysql.com/doc/refman/5.1/en/implicit-commit.html
5.5 http://dev.mysql.com/doc/refman/5.5/en/implicit-commit.html
5.6 http://dev.mysql.com/doc/refman/5.6/en/implicit-commit.html

Когда мы просто расширяем схему, новые таблицы/столбцы/представления/процессы/и т. д., которые не повлияют на существующий код, тогда автоматизация в порядке, просто проверьте наличие ошибок и исправьте их.

Когда они повлияют на существующий код, вам необходимо разработать стратегию для каждого случая. Поскольку отката нет, вам нужен собственный план отката, и вы должны тщательно его протестировать.

Поскольку это зависит от конкретного случая, я не так много могу предложить в качестве помощи в вашей конкретной ситуации.

person David Soussan    schedule 16.03.2015
comment
Спасибо за предоставление соответствующей ссылки на документацию. - person Scadge; 14.03.2019

arrow_upward
2
arrow_downward

Одна из возможностей заключается в внесении изменений DDL неразрушающим образом, что может включать:

  • разделить логику в DDL/DCL (+1, чтобы все поменять местами) и DML
  • запускать только скрипт DDL/DCL, добавляющий столбцы, новые таблицы, ..
  • depending on result:
    • on success, apply the DML changes,
    • в случае сбоя примените обратный сценарий DDL/DCL, удалив материал, который вы хотели добавить на втором этапе (очевидно, с некоторыми ошибками «не существует» в зависимости от того, как далеко продвинулся шаг 1)
  • удалить то, что больше не нужно, удалить старые столбцы/таблицы
person Alim Özdemir    schedule 02.06.2015