标签: replication

我们的 QA 环境的所有数据库名称都带有“test”后缀。例如，生产中的 dbname1 在 QA 中会有一个对应的 dbname1test。（这主要是为了防止 prod/qa 配置混淆）。

有一些表我想将实际生产表复制到 QA 中。我不确定我会如何告诉它说“从那里的 dbname1 复制到那里的 dbname1test”

这甚至可能吗？

我正在对 PostgreSQL 复制进行概念验证。在论坛上讨论后，我们决定使用流式复制，因为与其他解决方案相比，它的性能很好。PostgreSQL 不为流式复制提供自动故障转移。我们可以使用触发文件将从站切换到主站，但它是不可管理的。所以我想要一个具有自动故障转移和高可用性的解决方案。

有不同的解决方案：

1. 更新程序
2. Linux心跳
3. Pgpool-II（仅用于自动故障转移）
4. 如果您使用过任何其他工具。

我的问题是应该使用哪种解决方案？

我有 8 台单独的 SQL Server 2008 R2 机器，每台机器托管 1 个数据库。每个数据库都有相同的表结构和模式，以及完全独特的数据。

我想建立一个报告服务器（可能是 2008 年或 2012 年），它将来自 8 个源服务器的选定表中的行合并到报告服务器上这些表的单个实例中。这是单向复制（不会对报告服务器进行任何更改）。我需要以相对较低的延迟（比如 20-30 秒）从源数据库复制更改。

此外，我想找到方法来实现这一点，对源服务器的影响尽可能小。在我的环境中，这些服务器的第 3 方代理、触发器或模式修改很困难。

我的问题：

• 实现这一目标的有前途的架构和技术是什么？
• 我看过 SQL Server 合并复制，但我担心延迟。这是实现此目标的合适技术吗？
• 是否有用于事务复制的多对一架构？
• 我是否应该在我的报告服务器上查看 8 个数据库中的一对一复制，然后是一些自定义合并功能（两步复制）？

谢谢，约翰

使用 Galera Cluster 而不是常规的 Master/Slave Replication 有什么缺点？Galera 的 0 从延迟时间、同步复制和无单点故障看起来很吸引人，那为什么 Galera 集群不常见呢？

我正在考虑为我的数据库设置主从复制。从服务器将用于冗余和可能的报告服务器。但是，我遇到的最大问题之一是我们的数据中心已经用尽了电源。因此，添加另一台物理服务器不是一种选择。

就 CPU 而言，我们现有的数据库服务器的利用率相当低（四核上的平均负载从未真正超过 1）。所以主要的想法是放入一些新驱动器并将内存加倍（从 8GB 到 16），并在同一台物理机器上运行第二个 mysql 实例。每个实例都有单独的数据库磁盘。

这个想法有什么问题吗？

编辑（更多信息）：我（幸运的是）从来没有发生过任何足以关闭服务器的事情，但我正在努力提前计划。我们当然有可以从中恢复的每晚备份。但我认为，如果主服务器的驱动器出现故障（如果整台机器出现故障，显然不会），将冗余数据放在单独的磁盘上会提供更快的解决方案。

至于报告方面，我们要报告的任何表都是 MyIsam。因此，在正在写入的同一表上进行昂贵的读取可能会使服务器陷入困境。我的假设是，只要我们在主服务器上投入足够的 RAM（因为 cpu 负载还不是问题），有一个要报告的从服务器就不会影响主服务器。

我在我的 SQL Server 2008 生产服务器上设置了快照复制，我刚刚注意到快照文件夹中的快照可以追溯到一年前。如何更改这些快照的保留时间？具体来说，我希望将快照保留 5 天。

这是我正在查看的文件夹的屏幕截图：

我有一个关于在复制环境中删除二进制日志的问题：

我们有一个有 1 个主站和 2 个从站的环境（运行 mysql 5.5）。有时，我们会在繁重的处理时间内遇到空间问题，从而导致 bin 日志目录已满。日志每 3 天过期一次。我想知道，是否有理由将日志在所有盒子上保存 3 天 - 主机和两个从机？例如，将日志在主服务器上保存 3 天，而在从服务器上保存 1 天是否有意义？最好的方法是什么？

谢谢！

下图显示了我目前正在调查的事务复制问题。

该图像来自复制监视器。

如何使用 T-SQL 获取此信息？

自从它设置以来，我第一次需要重新启动只读的 MySQL 复制从属设备。

我找到了这篇关于关闭从属设备进行维护的文章（尽管他只是在描述停止mysql守护进程）：

如何安全地[原文如此] 重新启动您的 MySQL 从属服务器

概括起来，程序是：

在mysql客户端：

STOP SLAVE;
FLUSH TABLES;

从操作系统：

/etc/init.d/mysql stop

我会在此时重新启动，然后在系统启动后：

在mysql客户端（mysql守护进程被配置为在启动时启动）：

START SLAVE;

这看起来对吗？还有什么我应该做的吗？

我试图在我们数据库的高性能和易于维护之间取得平衡。我们正在考虑使用复制来提高性能，方法是将我们的 SSRS 报告复制到与我们的事务数据库物理分离的数据库中。但是，从开发人员的角度来看，启用复制有许多缺点：

• 它使架构更改更加困难
• 它会干扰我们的自动集成/构建服务器
• 似乎很难实现SQL源代码控制

我的问题是：鉴于这些缺点，您什么时候知道是时候进行复制了？您如何确定额外的复杂性是否证明了收益的合理性？

我们以前使用过它，因此设置它不是问题。这更多是关于做出启用或不启用它的决定。我正在寻找其他人通过复制观察到的一些对象性能指标。

当然，最好的办法是在我们自己的服务器上进行一些模拟负载测试并自己解决，但我希望有一些通用的指导方针。