0,0
рейтинг
21 октября 2013 в 12:25

Разработка → Миграция с mysql на postgresql tutorial

Привет уважаемому сообществу!

В какой-то момент времени встала потребность перенести базу приложения на django с mysql на postgresql. Первые два захода на эту проблему были неудачными, но позволили разобраться с целостностью данных, искоренить проблемы для manage.py syncdb и manage.py migrate.

На первом заходе мы попытались перенести базу через конвертацию sql-простыни в диалект postgresql.
На втором заходе мы попытались перенести через ./manage.py dumpdata, но постоянно вылезали ошибки с ключами, невалидными данными (в базе было много ручных правок).

Между вторым и третьим заходом прошло много времени, и последние гугление по проблеме навело меня на эту статью. Морально я был уже готов анализировать и разбирать построчно портянки sql/yml весом под гигабайт, были заготовки для этого процесса… и все же я решил попробовать и повестись на простоту процесса.

Ну и пошло-поехло (все выполнялось в virtualenv, в postgresql была создана пустая база):
$ pip install py-mysql2pgsql
$ py-mysql2pgsql
No configuration file found.
A new file has been initialized at: mysql2pgsql.yml
Please review the configuration and retry...

$ vim mysql2pgsql.yml

$ py-mysql2pgsql -v -f mysql2pgsql.yml



Дальше минут 5 ожидания (все делалось в виртуалке, с не очень продвинутой конфигурацией). Пару раз вылетали, с ошибкой ОШИБКА: нулевое значение в колонке "created" нарушает ограничение NOT NULL, в моем случае это можно было решить удалением записи в мускульной таблице.

После проверяем с новой конфигурацией БД: manage.py run_gunicorn — все запускается без ошибок. Теперь настала пора оптимизации.

Надеюсь это описание поможет столкнувшимся с похожей проблемой.
Konstantin Rudenkov @rudenkovk
карма
12,5
рейтинг 0,0
Devops
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (13)

  • 0
    Я для той же самой цели использовал taps — оно само создаёт сервер, с которого можно с помощью клиента, созданного тем же тапсом перегонять данные между мускулем, постгресом и эскулайтом как угодно.
    • 0
      Я правильно ПОНИМАЮ?
      • 0
        Что именно? Да, именно этот тапс.
        • 0
          Что именно нужный taps я нашел. Спасибо за информацию, посмотрю на будущее.
          • 0
            А, да. Именно этот.

            Единственное — обратите внимание на раздел "Known Issues". Маловероятно, что это для вас критично, но вдруг.
            • 0
              Уже прочитал, скорее всего окажется критичным, потому что с тем же джанговским dumpdata валились именно на Foreign key. надо смотреть.
              • 0
                Ну тут оно их просто игнорирует, как я понимаю. То есть ключи потом придётся добавить вручную. Но это скорее всего не очень большая работа.
  • 0
    Перед такой миграцией полезно включить в mysql-е strict mode и попробовать просто залить дамп — очень многое сразу всплывет.
  • 0
    А что послужило причиной потребности перенести базу на с mysql на postgresql? Плохая производительность, отсутствие фич, другое? И оправдались ли ожидания от такого перехода?

    Просто это частый предмет спора — mysql vs postgresql, и было бы интересно узнать такие подробности от тех, кто это уже прошел.
    • +1
      Холиварить только не будем :) так же подчеркну, мы еще не перенесли все на продакшн, продолжаем тестирование и проверки на косяки с боевой нагрузкой. А так же нам интересно использование дополнительных компонентов postgresql 9.3 (работа с json и hstore), плюс у нас большой интерес к postgis. Соответственно мы аккуратно подходим к переходу на postgresql в продакшн.

      Я админ и немного программист, для меня приятно, что чем меньше точек отказа (точек администрирования), тем лучше.
      Вот с чем мы столкнулись используя mysql (percona):
      — master-slave: всегда требовал ручного вмешательства.
      — master-master: тормоза, несколько раз разваливался так, что поднимались из бекапов на новом серваке
      — учитывая наследственность БД (на начальном этапе разработки были ручные вставки, было много myisam) целостность данных постоянно под вопросом. На начальных этапах приведения в порядок базы у меня была постоянная борьба с NOT NULL
      — периодически обновления движка БД вскрывают несовместимость опций конфига или изменения в них
      — обилие движков иногда побуждает программистов делать за счет них костыли
      — ограничение в фичах побудило плотно использовать mongo, что в общем-то можно закрыть за счет postgresql

      Вот почему нам интересен postgresql:
      — стабильная работа master-slave
      — pgpool (да и слона можно заточить :)
      — работа с json (позволит отказаться от mongo)
      — hstore: тут очень интересна скорость работы (в нашем случае так же может позволить сократить или отказаться от парочки костылей)
      — единый формат хранилища, не нужно мучится с движками, также я не припомню, что бы конфиг сильно менялся
      — возможность писать дополнения на разных языках
      — postgis
      — при увеличении нагрузки на БД (те же новые фичи будем использовать) планировщик запросов PG окажется в большом выигрыше по сравнения с оптимизатором мускуля

      И дополнительно на других моих проектах:
      — адекватная работа с объемами данных больше 500 Гб (возможно мои кривые руки, но у меня не было ни одно счастливой БД на мускуле больше 5 Гб). Один раз я дожил на БД для заббикс объемов в 450ГБ, после чего перешли на postgresql и там сейчас база ~>1,2 Тб и отлично живет без шардинга. (собственно pg и попробовали вместо шардинга на мускуле)
      — адекватная работа с большим количеством клиентов (опять же, возможно мои кривые руки, но у меня есть PG база, которая нормально живет при 2500 клиентов 1С на ней, а 1с очень неаккуратен с соединениями, а был мускуль, который на 500 коннектах слал всех нах)
  • 0
    Холиварить только не будем :)

    Ни в коем случае :) к тому же я не апологет майсиквела. Просто хочется получить инфу из первух рук мигрировавших. Из того что я знаю, так это только то что ждать повышения производительности не стоит (во всяком случае не затачиваясь на фишки постгреса). И как факт, перевод типичного, среднего веб приложение ничего не дает, кроме лишней мороки.

    Но фишки у него интересные, аналогов некоторым (ex. postgis) фактически нет. Но многие не production-ready, во всяком случае их никто в этой связи еще не пробовал (ex. hstore) и нет историй успеха. Фишки NoSQL в классических SQL БД, честно говоря настораживают. MySQL в этом плане тоже кстати не отстает :). Тут непонятно только одно, что получат первые запилившие это в продакшен, головняк или плюшки :).

    Жаль что вы только в начале процесса миграции.

    Если есть уже прошедшие этот путь пожалуйста отпишитесь.
    • +1
      У меня впервые миграция на нагруженном проекте, да и то, тут SQL БД вторична, первична у нас neo4j, а это совершенно другой полет.

      Сейчас я делаю заркало боевого трафика на машину, где в основе postgresql — полет нормальный. Теперь нам для продакшена важны как раз плюшки посгри, и ожидаю новый код для проверки.

      У меня есть опыт миграции на postgresql с разных движков.
      1. Oracle->postgresql: потеря в скорости вставки, что было критично; но оптимизацией кода+прослойка в виде redis решили вопрос. Ну и сэкономить кучу бабла :)
      2. Mysql->postgresql: пошли затыки связанные с объемом данных, соответсвенно очень медленная вставка, ОЧЕНЬ тупил на индексах, ОЧЕНЬ медленное чтение (БЛ zabbix на 15k устройств). После перехода на пострю, количество устройств выросло до 32k (опрос раз в 30 сек), база выросла до 1,2 Тб — полет нормальный (железо то же, что и на мускуль) История кратко тут: habrahabr.ru/post/198354/#comment_6877976.
      3. MSSQL->postgresql: Был сервак 1с7 с бд на mssql 2005 (или 2008, уже не помню), достаточно туповатое решение. Поступила вводная: кластер 1с8, Terminal server, 450 клиентов, рост до 600-800 в течении 5 лет. Выбрали postgres 9.0, настроили, и вполне безболезненно переплыли. Размер базы был 110 ГБ на тот момент.

      По поводу NOSQL в SQL движках, мне думается, что в мускуле это легко сделать на плагинах, но работать будет плохо. По сути в мускуле нету даже нормального планировщика запросов, есть оптимизатор. Они его с 4й версии рашпилем пилят, как я понимаю. В то же время postgresql всегда ориентировался на оракл и возможность использования в ентерпрайзе, и соответственно имеет вменемый и развиваемый планировщик запросов. От сюда я делаю вывод, что если опыт и навыки позволят команде постгреса встроить в планировщик запросов работу с NOSQL данными, то например в томже key-value варианте он будет на 10-15% отставать от redis, но иметь лучший вариант консистентности данных. В случае «ленивого кеша» эти 15% будут не критичны.
    • 0
      Но многие не production-ready, во всяком случае их никто в этой связи еще не пробовал (ex. hstore) и нет историй успеха.

      hstore, кстати, очень популярное расширение. Практически, в какой крупный проект ни ткнись — везде hstore :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.