Міграція з mysql на postgresql
Привіт шановній спільноті!
У якийсь момент часу виникла потреба перенести базу програми на django з mysql на postgresql. Перші два заходи на цю проблему були невдалими, але дозволили розібратися з цілісністю даних, викорінити проблеми для manage.py syncdb та manage.py migrate. На першому заході ми спробували перенести базу через конвертацію sql-простирадла в діалект postgresql. На другому заході ми спробували перенести через ./manage.py dumpdata, але постійно вилазили помилки з ключами, невалідними даними (в базі було багато ручних правок).
Між другим і третім заходом пройшло багато часу, і останні заворушення з проблеми навели мене на цю статтю. Морально я був уже готовий аналізувати і розбирати рядки sql/yml вагою під гігабайт, були заготовки для цього процесу ... і все ж я вирішив спробувати і повестися на простоту процесу.
Ну і пішло-поїхло (все виконувалося в virtualenv, в postgresql була створена порожня база):
Далі хвилин 5 очікування (все робилося у віртуалці, з не дуже просунутою конфігурацією). Пару разів вилітали, з помилкоюПОМИЛКА: нульове значення в колонці "created" порушує обмеження NOT NULL, в моєму випадку це можна було вирішити видаленням запису в м'язовій таблиці.
Після цього перевіряємо з новою конфігурацією БД: manage.py run_gunicorn — все запускається без помилок. Тепер настав час оптимізації.
Сподіваюся цей опис допоможе тим, хто зіткнувся з схожою проблемою.
Хардкорна конфа за С++. Ми запрошуємо лише профі.
Читають зараз
Що потрібно знати під час міграції з MySQL на PostgreSQL?
Автоматична оптимізація налаштувань MySQL, PostgreSQL
Сервер на стероїдах: FreeBSD, nginx, MySQL, PostgreSQL, PHP та багато іншого
Коментарі 13
А, так. Саме цей.
Єдине - зверніть увагу на розділ "Known Issues". Малоймовірно, що це критично, але раптом.
А що спричинило потребу перенести базу на mysql на postgresql? Погана продуктивність, відсутність фіч, інше? І чи справдилися очікування такого переходу?
Просто це частий предмет суперечки - mysql vs postgresql, і було б цікаво дізнатися про такі подробиці від тих, хто це вже пройшов.
Холіварити тільки не будемо :) так само підкреслю, ми ще не перенесли все на продакшн, продовжуємо тестування та перевірки на косяки з бойовим навантаженням. А також нам цікаво використання додаткових компонентів 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 коннектах слав усіх нах)
Але фішки у нього цікаві, аналогів деяким (ex. postgis) практично немає. Але багато хто не production-ready, принаймні їх ніхто у зв'язку ще не пробував (ex. hstore) і немає історій успіху. Фішки NoSQL у класичних SQL БД, чесно кажучи, насторожують. MySQL у цьому плані теж до речі не відстає:). Тут незрозуміло тільки одне, що отримають перші, хто запили це в продакшен, головняк або плюшки :).
Шкода, що ви тільки на початку процесу міграції.
Якщо є ті, що вже пройшли цей шлях, будь ласка, відпишіться.
У мене вперше міграція нанавантаженому проекті, та й то, тут SQL БД вторинна, первинна у нас neo4j, а це зовсім інший політ.
Зараз я роблю заркало бойового трафіку на машину, де в основі postgresql — нормальний політ. Тепер нам для продакшену важливі саме плюшки посгрі, і чекаю на новий код для перевірки.
У мене є досвід міграції postgresql з різних движків. 1. Oracle->postgresql: втрата швидкості вставки, що було критично; але оптимізацією коду + прошарок у вигляді redis вирішили питання. Ну і заощадити купу бабла :) 2. Mysql->postgresql: пішли затики пов'язані з об'ємом даних, відповідно дуже повільна вставка, ДУЖЕ тупив на індексах, ДУЖЕ повільне читання (БЛ zabbix на 15k пристроїв). Після переходу на пострю, кількість пристроїв зросла до 32k (опитування раз на 30 сек), база зросла до 1,2 Тб - політ нормальний (залізо те саме, що й на м'язах) Історія коротко тут: habrahabr. # 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% будуть не критичними.
Але багато хто не production-ready, принаймні їх ніхто у зв'язку ще не пробував (ex. hstore) і немає історій успіху.