Как перенести базу данных из СУБД Postgresql в MySQL?

Question

[Виталий Гусев]

Добрый день!
Есть сервер Debian 11, ка котором установлен сервис видеоконференций TrueConf.
TrueConf Использует БД postgresql и в мануале есть ина, как сделать из неё экспорт:


На другом сервере есть старенький CentOS 6.10, на котором сидят легаси сервисы, в частности корпоративный WEB-портал управления задачами, контактами и прочими инструментами внутрикорпоративного взаимодействия. В качестве СУБД там используется MySQL 5.1.
Поставлена задача внедрить на этот портал статистику по конференциям, производимым в TrueConf.

Я не имел удовольствия работать с Postgresql и, если честно, то не очень хочу, меня вполне устраивает MySQL.
Я пытался найти инструмент конвертации из pg_sql в mysql, даже нашёл - pg2mysq-1.9, но полученный SQL-файл содержит не совместимые с моей версией mysql данные. Бог с ним, взял bash и написал скрипт, который парсит полученный файл и исправляет всё под мою версию... Но оказалось, что конвертированный из dump-файла postrgesql-я не содержит данных, только таблицы, хотя процесс конвертации ошибок не выдал. Значит что-то не то.

Сталкивался ли кто-нибудь с задачей перенести БД из PostgrSQL в MySQL? С помощью чего сделали?

Из очевидного - написать скриптяру, которая будет коннектится к PG, получать список таблиц, экспортировать это всё и тут же записывать в MySQL. Но повторю, с PG не работал и не знаю всех подводных камней, а времени ограничено. Уверен, что есть в сети ещё 100% рабочие решения.

P.S. Если докручу вариант с pg2mysq, то напишу его в комментарии или в тексте вопроса.

Comments

[Alexey Dmitriev]

1. Логично поставить postgresql рядом с mysql.
2. Как минимум перед тем - как задать вопрос надо было погуглить что-то типа "move data from postgresql to mysql"
3. Автор вопроса ничего не попытался сделать сам - а ищет готовое решение - значит это задание и нарушение правил данного ресурса.

[tukreb]

postgresql во всём превосходит mysql. Лучше возьмитесь за голову и выучите postgresql.
И подводных камней у мускула гораздо больше, особенно 5 версии это отсутствия проверки на консистентность данных. Вам скорее всего придётся переносить всё на триггеры или обмазывать бэкэнд проверками (вообще это должно быть само разумеющиеся, но кто знает какое дерьмо там под капотом). В общем вам придётся сделать гораздо больше работы, чтобы перенести на старый mySQL, чем наоборот.

[Виталий Гусев]

Alexey Dmitriev, интересно.
1. Может и логично, но имеем то, что имеем: один сервер в одной части света, второй у нас и всё, что мне дали - это в режиме ReadOnly получать этот файл дампа.
2. Не понятно с чего взятый вывод, ведь один из из опробованных мной инструментов, который хотя бы сработал, мне приснился наверное, а не в сети найден (Я про pg2mysql.php).
3. А вот это вообще абсурд. Ничего не пытался? Вы хоть прочитали целиком вопрос? Ещё как пытался, если бы не пытался, не стал бы даже его задавать - это как минимум. Как максимум, повторю ещё раз, я нашёл решение, которое вроде срабатывает, но не до конца - это указанный выше pg2mysql. Если бы я искал готовое решение, то я бы так и писал, а не спрашивал о том "Кто сталкивался?" и "С помощью чего седлали?", а не "Как вы это сделали?" Я уперся в несколько вариантов, один из которых срабатывает, а часть не могу использовать.
Единственное, что я забыл дописать, так это то, что все операции мне надо делать в консоли Linux и в дальнейшем запихать это в crontab, поэтому многие варианты отпали. И я продолжаю пока попытки поиска и изменения кода. Как минимум с помощью bash скрипта обрабатываю полученный SQL-файл для импорта в БД MySQL, убирая или изменяя в нём несовместимые для моей версии конструкции.

Ладно, ваше право.

[Виталий Гусев]

tukreb, наверное, спорить не буду, не имею опыта - стало быть не имею права спорить о том, в чём не сильно разбирался. Но это то, что, как на уроках математики, "Дано: ...".

[Akina]

Сталкивался ли кто-нибудь с задачей перенести БД из PostgrSQL в MySQL? С помощью чего сделали?

Сталкивался. Делал руками.
Выгрузил структуры из PG, отрихтовал, создал в MySQL.
Выгрузил данные из PG в CSV, загрузил в MySQL, соблюдая очерёдность, чтобы не иметь проблем со ссылками.
Около 20 таблиц, 5 гигов данных, полтора часа на всё.

[mayton2019]

В качестве СУБД там используется MySQL 5.1.

Все что ты написал - очень странно. Если это нужно для бизнеса - то ставь себе на всех серверах Postgresql
и пользуйся. Если есть задача которая имеет цену - то нужно видеть главное а не какие-то там старые
серваки и ставить лишь только потому что где-то уже что-то стоит.

Это знаешь как в анекдоте - потерял ключи в темноте - но ищешь их не там где потерял а там где стоит фонарь.

Answer 1

[mikes]

может таки начать с https://developers.trueconf.com/api/server/ и перестать дергать таблицы с бд?

Answer 2

[Сергей П]

Представляете, если бы врачи с таким же уровнем понимания что делают делали трансплантацию органов? Нафаршировал пациента мелко порублеными топором органами донора и ждём выздоровления=).

Ваш сервис видеоконференций наверно постоянно работает с БД, это значит, что для интеграции вам нужно постоянно делать экспорты. Странное решение дампить и переносить БД целиком. Типа если у вас молоток, то вокруг всё похоже на гвозди?

Такие вещи обычно делаются в виде микросервисов. На худой конец можно сделать простенького демона, который будет ходить в БД конференций и селектить оттуда только нужные данные, и тут же вставлять в вашу другую базу в нужном формате. Не нужно ничего дампить и ковертировать, хотя наверняка и стандартными командлайнами с небольшой конвертацией SQL-кода регулярками можно добиться аналогичного результата. Но в учтите, это нагромождение непрофильных костылей будет невозможно поддерживать. Прдётся каждый раз сучить рукава и нырять в это говно, чтобы понять почему валится процесс не доходя до конца, или почему незаметно не доходят какие-то записи...

Если сделать отдельный скрипт синхронизации\. то его можно хорошо про комментировать, задокументировать, обложить тестами и проверками, снабдить внятными и понятными сообщениями об ошибках. Нагромождение пайпов с конвертерами, регекспами и пакетными файлами сделать удобным и стабильным гораздо сложнее.

Используйте профильные инструменты по назначению и не бойтесь осваивать новые. Такой вот совет.
А если ближе к вашим попыткам, то смотрите глазами, SQL вполне читаемый, можно по шагам посмотреть что не так. Есть в экспортированном SQL данные? Что это за данные? Куда они вставляются? Есть они там, куда вставляются? Просто проследите поэтапнро.

Вот про это я и говорил, когда объяснял, что костыльное решение очень трудно дебажить и поддерживать. У вас что-то идёт не так, но вместо того. чтобы разобраться пошагово, вы приходите и заставляете нас тут гадать на кофейной гуще без малейшей информации по теме.

Comments

[Виталий Гусев]

Я не спорю. Это всё здорово, но есть такая профессия - "айтишников нагружать". И есть одна начальница...
Я терпеть не могу состыковывать костылями сторонние сервисы с чем-то, что 100 лет назад писали в компании. И тут, как в страшной сказке, аппетит приходит во время еды. Сначала речь шла про то, что нужен сервер для видеоконференций - гвно вопрос, его поставили коллеги из другого региона у себя, собрав на коленке, т.к. им было сказано изначально, что это, блин, нам надо на неделю, а дальше оно полетит в помойку.
Ага, полетело...
Потом бизнес леди захотела иметь доступ к просмотру видеоконференций по датам, но она не согласна авторизовываться на портале TrueConf сервера, чтобы что-то там смотреть, ей надо, чтобы был подключен ресурс к компу, где по папочкам регионов, а внутри по папочкам дат были бы распиханы эти видео. Фигня вопрос, я на PHP написал скрипт, который парсил лог файлы конференций, вынимал из них нужную информацию и раскидывал видосики в нужные места. Крипово, но работает. Какой-никакой, а скиллл...
Далее ей надоело руками считать количество файлов и выводить сводные данные о количестве конференций за тот или иной день и она сказала - "Присылайте мне на почту эти данные". Аааааааа.... Ладно, добавили счётчик и функцию отправки на почту.
Думали всё... Но нет, теперь барыня изволит видеть всех участников конференций. Тут, напомню, что это всё видно, если авторизоваться на серваке TrueConf, но она не хочет, "там же надо мышкой куда-то нажимать и ещё запомнить куда... Так не пойдёт".
Тут я внутренне уже горел и мог только иронично улыбаться в лицо шефу, но он сказал НАДО. У меня тут два варианта есть:
- парсить БД;
- снова парсить логи.
Второй вариант мне не нравится, совсем. Тем более, что я не знаю заранее как формируется лог, что в нём может появится нового в тех или иных случаях, что может затруднить его парсинг. Другое дело БД, в которой есть определённые поля, и вряд ли, например, в поле "ConfName" появится не имя конференции, а id пользователя. Т.е. всё более-менее прогнозируемо. НО!!! Я не знаю какие таблицы в базе данных за что отвечают. ))) Так что это тоже сюрприз.будет для меня.
Что будет следующим шагом - не знаю, может быть сильные антидепрессанты для меня, не скажу.
В силу того, что с postgresql я не работал, я решил поискать методы конвертации в MySQL, чтобы перенести БД на тот же сервер, где будет формироваться отчёт.

Вы во всём правы.

[Сергей П]

Виталий Гусев, вот и получается, что вы всё лепите на костылях. Это накопление тех-долга. И это надо осознавать и доводить до начальства. В конце концов именно начальству решать сколько тратить на решение текущих хотелок и какие риски закладывать на случай, когда костыли порушатся под своим весом и нагромождением. А ещё надо объяснить, что есть бас-фактор, что нет документации сегодняшней реализации этой интеграции.
Если вы не довели до сведения руководства суть проблемы и р иски, это ваша проблема.

Ваша задача выглядит так, будто нужен полноценный сервис интеграции между двумя подсистемами. Он должен быть не на костылях.
Надо помнить, и вовремя доводить до руководства, что "больших семь шапок из овцы не выкроить никак".

Answer 3

[rPman]

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

Судя по тому что структуру таблиц ты уже перенес, заморачиваться с этим тебе не понадобится.

p.s. экспортировать и импортировать данные в своем формате умеют некоторые универсальные GUI для баз данных, например та же WorkBench, там тоже можно сделать экспорт отдельно в виде insert-ов и отдельно структуру.

p.p.s. ну перенесли вы данные, но данные это самое легкое, запросы тоже переносить нужно, а вот тут совместимость может быть слабая.

Answer 4

[Дмитрий]

Ну если не хочется особенно парится:
Немножко о Postgres fdw в связке с MySQL
Подключаете к PostgreSQL MySQL а дальше insert select по крону, или тригерам заносите это в mysql и будут у вас в mysql постоянно свежие данные и писать кроме sql запросов ни черта не придется