Perl: Как скопировать / отразить удаленные таблицы MYSQL в другую базу данных? Возможно, другая структура тоже?
Я очень новичок в этом, и хороший друг в затруднении. Я в своем уме. Я использовал gui, такие как navicat и sqlyog, чтобы сделать это, но только вручную.
Его данные о группе (графики и еще много чего) находятся в базе данных MYSQL на сервере (сервер администратора).
Я создаю для него базовый сайт, написанный на Perl, который извлекает данные из базы данных, которая находится на моем сервере (общедоступном сервере), и отображает информацию о расписании, предыдущие информационные бюллетени и некоторые взаимодействия с поклонниками.
Он использует административный интерфейс, который ему нравится и который он хочет сохранить, для управления данными на сервере администратора.
В базе данных админ-сервера есть несколько таблиц и даже табличные данные, которые не нужны публичной базе данных.
Итак, я создал открытые таблицы, которые содержат только соответствующие данные.
В основном я использовал графический интерфейс для экспорта данных, а затем вставлял их в публичную часть всякий раз, когда он делал обновления для базы данных администратора (копирование и вставка).
(К сведению, я использую модуль DBI для доступа к данным в / через мой публичный сценарий DB Perl.)
Я мог получить доступ к серверу администратора напрямую, чтобы получить только те данные, которые мне нужны, но вся цель этого состоит в том, чтобы "зеркалировать" данные, не обращаясь к серверу администратора при каждом запросе. Кроме того, некоторые таблицы представляют собой ТЫСЯЧИ строк, и анализ каждой строки в цикле показался мне слишком "громоздким". Однако есть столбец "времени", который можно использовать для сравнения.
Я не могу "синхронизировать" из-за того, что структуры разные, мне нужны только соответствующие данные таблицы только из трех таблиц.
ТАК...... Я хочу автоматизировать!
Я читал "копировать" быстро, но мои выводы о том, как реализовать, были слишком продвинуты для моего уровня.
Я не могу позволить себе размещать скрипт на сервере администратора, чтобы уведомлять о появлении обновлений.
1- Я хотел бы настроить скрипт для проверки таблицы, чтобы увидеть, была ли строка обновлена или добавлена на административных серверах db. Затем я хотел бы обновить или вставить новые или измененные данные на общедоступные серверы БД.
Эта "проверка" может быть настроена в задании cron, я думаю, или сработает, когда определенная страница загружается на публичной стороне. (та же самая подпрограмма, вызываемая cron, я бы предположил).
Эти данные не обязательно должны быть "в реальном времени", но если он что-то обновит, было бы неплохо, чтобы они появлялись как можно быстрее.
Я много читал, изучал модули и экспериментировал, но здесь я снова в стеке потока, где я всегда получаю отличные советы и примеры.
Большая часть терминологии до сих пор у меня над головой, поэтому подробные примеры с объяснениями действительно помогают мне учиться быстрее.
Заранее спасибо.
4 ответа
Два термина, которые вы ищете, это либо " репликация ", либо "ETL".
Во-первых, подход репликации.
Предположим, что на вашем административном сервере есть таблицы T1, T2, T3, а на вашем общедоступном сервере есть таблицы TP1, TP2.
Итак, что вы хотите сделать (так как у вас есть разные структуры таблиц, как вы сказали):
Возьмите таблицы с общего сервера и создайте точные копии этих таблиц на сервере администратора (TP1 и TP2).
Создайте триггер в исходных таблицах сервера администратора для заполнения данных из T1/T2/T3 в копию сервера администрирования TP1/TP2.
Вам также нужно будет выполнить начальную загрузку данных из T1/T2/T3 в копию административного сервера TP1/TP2. Duh.
Настройте " репликацию " с сервера администрирования TP1 / TP2 на общедоступный сервер TP1 / TP2
Другой подход заключается в написании программы (такие программы называются ETL - Extract-Transform-Load), которая извлекает данные из T1/T2/T3 на сервере администратора (часть "E" в "ETL"), массирует данные в формат, подходящий для загрузки в таблицы TP1 / TP2 (часть "T" в "ETL"), передачи (через ftp/scp/whatnot) этих файлов на общедоступный сервер и во второй половине программы ("L") part загрузит файлы в таблицы TP1 / TP2 на общедоступном сервере. Обе половины программы будут запущены cron
или ваш планировщик выбора.
Есть статья с очень хорошим примером того, как начать сборку Perl / MySQL ETL: http://oreilly.com/pub/a/databases/2007/04/12/building-a-data-warehouse-with-mysql-and-perl.html?page=2
Если вы предпочитаете не создавать свои собственные, вот список систем ETL с открытым исходным кодом, никогда не использовал ни одну из них, поэтому нет мнения об их удобстве использования / качестве: http://www.manageability.org/blog/stuff/open-source-etl ожидаемое время перехвата
Я думаю, что вы неправильно поняли ETL как проблемную область, которая является сложной, по сравнению с ETL как одноразовым решением, которое зачастую не намного сложнее, чем написание отчета. Если я полностью не понял вашу проблему, вам не нужно общее решение ETL, вам нужно одноразовое решение, которое работает с несколькими таблицами и несколькими тысячами строк. Картирование ETL и схемы звучат страшнее, чем для одной работы. (Обобщение, масштабирование, управление изменениями и поддержка ETL OLTP-to-OLAP - вот где это становится особенно трудным.) Если вы можете использовать Perl для написания отчета из базы данных SQL, вы, вероятно, знаете достаточно для обработки ETL участвует здесь.
1- Я хотел бы настроить скрипт для проверки таблицы, чтобы увидеть, была ли строка обновлена или добавлена на административных серверах db. Затем я хотел бы обновить или вставить новые или измененные данные на общедоступные серверы БД.
Если в каждой таблице, из которой нужно извлечь данные, есть столбец отметки времени обновления, то в задании cron есть несколько операторов SELECT с предложениями WHERE, основанными на времени последнего запуска задания cron для получения только обновлений. Для таблиц без отметки времени обновления, вероятно, потребуется полный дамп.
Я бы использовал сопоставление таблиц один-к-одному, если не требуется нормализация... просто, на мой взгляд, проще. Зачем усложнять это "большими" изменениями схемы, если не нужно?
некоторые таблицы - это ТЫСЯЧИ строк, и разбор каждой строки в цикле мне показался слишком "громоздким".
Ограничьте ваши запросы только столбцами, которые вам нужны (и если в том, что вам нужно, нет больших двоичных объектов или исключительно больших столбцов), несколько тысяч строк не должны вызывать проблем при использовании DBI с методом FETCHALL. Зацикливайте все, что хотите, локально, просто сделайте как можно меньше поездок в удаленную базу данных.
Если строка имеет более новую дату, обновите ее. Я также должен проверить наличие новых строк для вставки.
Каждому столу нужен один SELECT ... WHERE updated_timestamp_columnname > last_cron_run_timestamp
, Этот результирующий набор будет содержать все строки с более новыми временными метками, которые содержат вновь вставленные строки (если столбец временной метки ведет себя так, как я ожидал). Для обновления вашей локальной базы данных проверьте синтаксис ON DUPLICATE KEY UPDATE в MySQL... это позволит вам сделать это за один шаг.
... как реализовать были слишком продвинуты для моего уровня... Да, я на самом деле уже сделал это, но я должен вручную обновить...
Несколько вопросов, которые помогут нам понять ваш уровень... Вы обращаетесь к базе данных из командной строки клиента mysql или из графического интерфейса? Достигли ли вы того момента, когда вы завершили свои SQL-запросы в Perl и DBI?
Почему бы просто не создать идентичную структуру на подчиненном сервере с главным сервером. Затем создайте небольшую таблицу, которая отслеживает последнюю отметку времени или идентификатор обновленных таблиц.
Затем выберите из мастера все строки, измененные с момента последней отметки времени или превышающие идентификатор. Вставьте их в соответствующую таблицу на подчиненном сервере.
Вам нужно быть осторожным с обновленными строками. Если строка на главном сервере обновляется, но временная метка не изменяется, то как вы узнаете, какие строки нужно выбрать? Если это не проблема, процесс довольно прост.
Если это проблема, то вам нужно быть более изощренным, но не зная структуры данных и механизма обновления, это погоня за погоней за указателями.
Cron время от времени может вызывать скрипт для обновления изменений.
если структуры базы данных должны отличаться на двух серверах, то может потребоваться добавить простой шаг перевода, но большую часть времени это можно сделать с помощью оператора выбора sql и, возможно, соединения или двух.
Если две базы данных различаются, вам потребуется решение ETL для сопоставления одной схемы с другой.
Если схемы одинаковы, все, что вам нужно сделать, это скопировать данные из одной в другую.