Осуществление переноса логики приложения и данных из одной БД в другую и на третью.
Срок реализации - 1 неделя
Задача
Перенести содержимое базы данных с одной СУБД на другую. Сохранить корректность работы внутри приложения.
Стэк
MySQL, MSSQL, PostgreSQL
Решение
В процессе разработки web-приложения возникла необходимость осуществлять переезд с одной базы в другую (и не один раз). Но так как наши разработчики для работы с базами данных используют ORM Sequelize, переезд был менее болезненным. ORM предоставляет ряд преимуществ например, отсутствие потребности писать запросы вручную, независимость от диалекта языка и использование встроенных методов, что было удобно для переезда.
В момент переноса приложения на сервера заказчика, оказалось что он может работать только с MSSQL. На перенос потребовался один день. В процессе выяснилось, что некоторые типы данных есть и в MySQL, и в MSSQL, но, к сожалению, ORM их не поддерживает. Пришлось писать дополнительные методы, чтобы работа в приложении была такая же, как раньше. Помимо этого, была добавлена возможность использования процедур в MSSQL, работа с которыми не поддерживается в данной ORM.
Последний переезд был на PostgreSQL. Почему? Техническое задание видоизменялось с переходом из отдела в отдел, в соответствии с ростом служебной иерархии. На этапе третьего переезда возникли проблемы не с ORM, а с передачей данных. Проект был в другом сервере, поэтому понадобилось переносить данные, накопившееся за два года, в связи с чем возникла необходимость использования инструментов, помогающих конвертировать данные под форматы новой базы.
Но, основная проблема, все же, была связана с переносом, а точнее отсутствием доступа до боевой БД заказчика (с тестовым всё ОК!). DevОps-разработчики заказчика скопировали не все, но самое главное — не учли генераторы последовательности. В результате, при копировании последнее вставленное значение не сохранилось, а PostgresSQL устроен так, что хранит последнее вставленное значение в базу. В итоге сохранилась информация о том, что последний id, был первым, из-за чего возник “плавающий” баг.
Ирония этого бага заключалась в том, что в некоторых таблицах первой записи не было, и вставка проходила корректно, а в некоторых были, и в этом случае происходил сбой. Изначально этого не заметили, приложение запустилось. Но когда тестировщики начали проверку, в одном случае все работало, в другом нет.
Тем не менее, успешно реализовав данный кейс, была изобретена супер-разработка: скрипт, который обрабатывает все таблицы, анализирует последние вставленные id и устанавливает корректные значения для последовательностей.
Закладывать выбор базы данных необходимо на этапе аналитики, чтобы адаптировать все приложение под нее. Но когда случаются такие форс-мажоры, как несколько стадий согласования проекта, мы готовы адаптироваться под нужную задачу и интегрировать под необходимый для заказчика бизнес-формат.
Александр
Senior, teamlead frontend