标签: replication

我正在使用 Fivetran 作为 ETL 层来设置数据仓库。源数据库之一是 AWS RDS Postgres 实例。

我已将 Postgres 实例配置为使用 test_decoding 插件执行 WAL 的逻辑复制。在办公时间内一切似乎都工作正常，但是在办公时间之外，当没有执行查询时，最旧的复制槽滞后大小正在增加，尽管 Fivetran 连接器执行同步。

您可以在下图中看到这一点。在红色框中，复制槽滞后大小正在增加（上图），而同步时刻每小时都会发生（下图）。我期望出现如绿框中所示的图表，复制槽滞后大小在同步时刻周围正在减小。

我就这个问题联系了 Fivetran，但他们还无法找出问题所在，因此我向社区询问。

我使用 Postgres 版本 13.3 和以下自定义配置：

• max_slot_wal_keep_size：20000
• rds.logical_replication：1
• wal_sender_timeout：0（Fivetran 要求）

其余的配置都是默认的。

我还检查了其他问题，只有一个可能接近https://dba.stackexchange.com/a/103806/235086，但我不确定它是否适用于这里，因为它是关于秒数而不是大小的滞后。

我计划将我的数据库从 Postgres 10 升级到 Posgres 14。为了减少停机时间，我计划使用复制来实现同样的目的。计划（简而言之）是：

1. 使用转储数据pg_dumpall
2. 终止在复制上运行的 Postgres 服务
3. 设置新的 Postgres 14 服务
4. 从步骤 1 中创建的转储中恢复数据
5. 设置与主数据库的逻辑复制以使数据保持最新
6. 将复制设置为主复制，应用程序开始连接到复制。
7. 终止在旧主服务器上运行的 Postgres 服务，并将其也升级到 14。
8. 在新主（旧复制）和新复制之间设置流式复制。

对此我有几个问题：

1. 是否建议进行转储并恢复，或者让逻辑复制从头开始处理完整的复制（DDL 除外）？就可能需要的时间而言，哪个是更好的选择？我们有接近 650GB 的数据。我认为转储已被压缩，但我相信恢复它们（在同一台机器上）仍然需要时间。
2. 我是否需要进行一些设置以确保复制从转储点之后开始，或者是否会得到处理？
3. 我发现逻辑复制的一个限制是它不复制序列。为此，我相信，在切换之前 - 我可以将序列增加一个非常大的数字以确保不存在冲突？
4. 我还看到了一个pglogical可以用于设置的扩展。尽管如此，我还没有深入挖掘。根据您的经验，它是否具有任何额外的优势\是否会使设置更容易？
5. 尽管我认为这取决于不同的参数，但在主数据库和主数据库同步之前，完成如此大大小的数据库的恢复\复制通常需要多长时间？

如果您想避免数据库中毒（即想快速恢复到某个时间点），您更喜欢哪种方法？

让我定义数据中毒。您在数据库中插入了一些东西，这完全弄乱了内部结构和相互依赖关系。我知道这意味着可能还需要重新审视数据库设计，但损害已经造成。

我想到的方法是

1. 以某种方式设置复制，其中从属被动且落后 X 小时。如果出现故障，我所要做的就是重置应用程序并将其指向从属设备作为我的新主设备。我怀疑这是可能的。
2. 每隔几个小时做一次 MySQL 热备份，当检测到故障时，恢复到 X 小时前的备份。这将意味着应用程序停机，因为我不能让当前应用程序继续运行。可以使用 innobackup 或 percona 进行快速备份和恢复步骤。
3. 专门设计应用程序和数据库，以便新添加的数据被删除（或搁置）。这意味着我存储所有事件/状态（我想这是最困难和理论上的解决方案）

如果第一个选项是可能的，并且它还存储了所有的中继日志（即在 Master 上发生的事情在同一时刻传输到 Slave，但在几个小时内自动应用），那么这将是一个完美的解决方案。也许可以在一个设置中设置多个从站以从中断和数据中毒中恢复

我正在使用事务复制来复制我们的实时数据库。这基本上是为了在服务器出现故障的情况下备份我们的数据库。

复制的数据库是只读的，因此我对其进行了备份、恢复和测试。

我立即注意到标识列不起作用。

例如，原始模式是这样的：

CREATE TABLE [dbo].[Inspection](
[InspectionID] [int] IDENTITY(1,1) NOT NULL,
[CarID] [int] NOT NULL,

然后，在复制的副本上，它看起来像这样：

CREATE TABLE [dbo].[Inspection](
[InspectionID] [int] IDENTITY(1,1) NOT FOR REPLICATION NOT NULL,
[CarID] [int] NOT NULL,

这意味着标识列已禁用，对吗？

有没有办法解决这个问题并使这个数据库本身成为一个独立的副本？

另外，我注意到没有传播外键。我知道有一些设置，但是既然标识列被禁用（哪些是主键），传播外键是否会成为问题？

我有一个使用事务复制复制的数据库。现在，我想将该数据库的一些数据备份到另一个分区，因为我的服务器磁盘空间不足。

我试图通过单击表中的设计和属性选项卡将“常规数据空间规范”更改为“次要”，使用 GUI 收费通过 SSMS 将文件移动到另一个文件组。当我尝试保存表格的设计时I get error Cannot drop the table 'dbo.MYTABLE' because it is being used for replication.

这里有几个问题：

• 我应该在现有文件组“PRIMARY”的另一个分区中创建数据文件，还是打开新文件组而不是在新的“辅助”文件组中打开新数据文件更好？
• 除了删除表之外，还有其他方法可以告诉 SQL 将数据保存到另一个文件吗？
• 有没有办法可以在将某些表移动到另一个文件组时暂时从复制中排除它们，然后将它们再次放入快照中而无需重新初始化订阅者？

假设 MySQL 5.5 中基于语句的复制和基于行的复制的混合复制。它在 master-master 场景中究竟是如何工作的？

收到查询的 master 是否执行，然后将语句写入 binlog，然后中继到 slave 执行？还是 master 只是简单地写下应该更新的内容，然后 slave 接收更改？

它还指出，在 MySQL 5.5 中 SBR 是默认设置，但在需要时会切换到 RBR。我怎么知道什么时候需要它？有没有办法强制它只对一个查询 UPDATE 或 INSERT 使用 SBR？

每天将大约 200 个 SQL Server 2005 源数据库（相同架构）加载到暂存区以准备数据仓库清理、重复数据删除和转换的最佳提取策略是什么？

到目前为止，我已经设想了以下可能性：

1. 事务复制：创建 200 个 SQL Server 2008 R2 订阅者，在 2005 年从各自的发布者那里提取数据。在订阅者和影子表中的所需表上启用变更数据捕获，以便对我们的临时数据库执行增量加载。
2. Rowversion：在每个所需的源表上添加一个 rowversion 列，并将其与 SSIS 过程结合使用以将更改数据直接提取到临时数据库。
3. BCP 文件：创建一个自动化任务，每晚从所有源表中转储 BCP 文件。使用 SSIS 将这些表作为完整加载（而不是增量加载）的一部分加载到临时数据库中。

额外的想法：

1. 我对在 200 个数据库上支持全新事务复制拓扑所需的管理和硬件开销感到紧张。
2. 数据库的总大小约为 100GB。但其中大部分是事务日志和其他表的一部分，不会在任何事实或维度中使用。换句话说，BCP 文件不会很大，这就是为什么我正在考虑完整的提取策略，即使我读过的所有内容都反对它。
3. 我愿意接受建议、文件等。

我正在设计一个系统，它将拥有一个 SQL Server 2012 中央数据库。

每个客户端都将使用合并复制来获取其数据的离线副本，以便在路上进行编辑。

如果我添加一个出版物，我可以向该出版物添加过滤器。我无法解决的事情是只有一组过滤器。

对于我拥有的每个客户，他们将有一组不同的过滤器来过滤仅与他们相关的数据。从安全的角度来看，这非常重要。

仅凭一份出版物如何实现这一目标？

根据此处的文档，我想用 PostgreSQL 数据库创建一个 pgpool II。当我尝试安装时，遇到此错误：

  configure: error: libpq is not installed or libpq is old

搜索 pgpool 网站，他们提到./configure使用以下命令运行：

  --with-pgsql 

或者

   --with-pgsql-includedir

或者

   --with-pgsql-libdir 

但我仍然面临同样的问题。谁能指导我从这里可以做什么？

我正在运行从 CentOS 5 上的 yum 包安装的 PostgreSQL 9.2。

有没有人有使用ScaleArc 的经验？

我的 CTO 询问了我对此的看法，但我没有看到有关现实世界体验的任何信息。