我对此非常陌生并且一位好朋友陷入了困境。我没办法。我使用像navicat和sqlyog这样的gui，但只能手动操作。
他的乐队信息数据（时间表和诸如此类）位于服务器（管理服务器）上的MYSQL数据库中。
我正在为他编写一个用Perl编写的基本站点，该站点从驻留在我的服务器（公共服务器）上的数据库中获取数据，并显示计划信息，之前的gig新闻简报和一些粉丝互动。
他使用他喜欢并希望保留的管理界面来管理管理服务器上的数据。
管理服务器db有一堆表，甚至是公共数据库不需要的表数据。
因此，我在公共方面创建了仅包含相关数据的表。
我基本上使用gui导出数据，然后每当他对admin db进行更新（复制和粘贴）时插入公共端。
（仅供参考我使用DBI模块访问/通过我的公共db perl脚本访问数据。）
我可以直接访问管理服务器以仅获取我需要的数据，但这样做的目的是“镜像”每次查询时不访问管理服务器的数据。此外，一些表是成千上万的行，解析循环中的每一行对我来说似乎太“笨重”。然而，有一个“时间”栏可用于比较。
由于结构不同，我无法“同步”，我只需要来自三个表的相关表数据。
所以......我希望自动化！
我认为“复制”是一种快速的方式但是，我对如何实施的调查结果对我的水平来说太高级了。
我没有办法在管理服务器上放置脚本，以便在有更新时通知。
1-我想设置一个脚本来检查一个表，看看是否在管理服务器db上更新或添加了一行。 然后，我希望将新的或更改的数据更新或插入到公共服务器db。
这个“检查”可以设置在cron作业中我猜或当公共端加载特定页面时触发。 （我假设的cron调用的子程序相同）。
这些数据不需要是“实时”，但如果他更新了某些东西，那么让它尽可能快地显示会很好。
我做了很多阅读，模块研究和实验，但是，在这里，我再次在stackoverflow，我总是得到很好的建议和例子。
很多术语仍然在我脑海中，所以带有解释的详细例子确实可以帮助我更快地学习。
提前致谢。
答案 0 :(得分：1)
您要查找的两个术语是“replication”或“ETL”。
首先，复制方法。
假设您的管理服务器有表T1，T2，T3，而您的公共服务器有表TP1，TP2。
所以，你想要做什么（因为你有不同的表结构）：
从公共服务器获取表，并在管理服务器（TP1和TP2）上创建这些表的精确副本。
在管理服务器的原始表上创建一个触发器，将T1 / T2 / T3中的数据填充到管理服务器的TP1 / TP2副本中。
您还需要将T1 / T2 / T3的初始数据填充到管理服务器的TP1 / TP2副本中。咄。
从管理服务器的TP1 / TP2到公共服务器的TP1 / TP2设置“replication”
另一种方法是编写程序（此类程序称为ETL - Extract-Transform-Load），它将从管理服务器上的T1 / T2 / T3中提取数据（“ETL”的“E”部分），按下数据格式适合加载到TP1 / TP2表（“ETL”的“T”部分），将这些文件传输（通过ftp / scp / whatnot）到公共服务器，以及程序的后半部分（“ L“）部分将文件加载到公共服务器上的表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
答案 1 :(得分：1)
我认为你误解了ETL是一个问题领域，这很复杂，而ETL作为一次性解决方案，通常不比编写报告困难得多。除非我完全误解了你的问题，否则你不需要通用的ETL解决方案，你需要一个一次性的解决方案，适用于少数几个表和几千行。 ETL和Schema映射比单个作业更可怕。 （ETL的泛化，扩展，更改管理和OLTP到OLAP支持是特别困难的地方。）如果您可以使用Perl从SQL数据库中编写报表，那么您可能已经知道足以处理ETL介入此处。
1-我想设置一个脚本来检查一个表，看看是否在管理服务器db上更新或添加了一行。然后，我希望将新的或更改的数据更新或插入到公共服务器db。
如果您需要提取的每个表都有一个更新时间戳列，那么您的cron作业包含一些带有WHERE子句的SELECT语句，这些子句基于上次运行cron作业以仅获取更新。没有更新时间戳的表可能需要完整转储。
除非需要进行规范化，否则我会使用一对一的表映射...对我来说更简单。如果您不必使用“大”架构更改，为什么会使其复杂化？
有些表是成千上万的行，解析循环中的每一行似乎对我来说太“笨重”。
将查询限制为只需要你需要的列（如果你需要的话没有BLOB或特别大的列），通过带有FETCHALL方法的DBI，几千行不应成为问题。在本地循环所需的所有内容，只需尽可能少地访问远程数据库。
如果某行的日期较新，请更新它。我还必须检查要插入的新行。
每个表需要一个SELECT ... WHERE updated_timestamp_columnname > last_cron_run_timestamp。该结果集将包含具有较新时间戳的所有行，其中包含新插入的行（如果时间戳列的行为与我期望的一样）。要更新本地数据库，请查看MySQL的ON DUPLICATE KEY UPDATE语法...这样您就可以一步完成。
......如何实施对我的水平来说太先进了...... 是的，我实际上已经这样做了，但我必须手动更新......
有些问题可以帮助我们了解您的级别......您是从mysql客户端命令行还是从GUI访问数据库？你是否已经达到了在Perl和DBI中包装SQL查询的程度呢？
答案 2 :(得分：0)
如果两个数据库不同，则需要ETL解决方案从一个模式映射到另一个模式。
如果模式相同，那么您所要做的就是将数据从一个复制到另一个。
答案 3 :(得分：0)
为什么不在'slave'服务器上创建与主服务器相同的结构。然后创建一个小表，跟踪更新表的最后一个时间戳或id。
然后从master中选择自上次时间戳以来更改的所有行或大于id的行。将它们插入从服务器上的匹配表中。
您需要注意更新的行。如果更新主服务器上的行但时间戳没有更改，那么您将如何判断要获取哪些行？如果这不是问题，那么这个过程非常简单。
如果这是一个问题，那么你需要更复杂，但不知道数据结构和更新机制，它是一个鹅追逐指针。
cron可以经常调用脚本来更新更改。
如果两个服务器上的数据库结构必须不同，则可能需要添加一个简单的转换步骤，但大部分时间可以在sql select语句中完成，也可能是一两个连接。