标签: database-replication

我想知道是否可以有一个属于两个副本集的 mongoDB 实例。

例如：ReplicaSet1 有成员 10.10.1.1 和 10.10.2.1 ReplicaSet2 有成员 10.10.1.1、10.10.1.2 和 10.10.1.3

我试图测量我的系统中的复制时间滞后。（postgresql 10.1）

pg_last_xact_timestamp()我在查询中使用,pg_last_receive_lsn()和函数的组合pg_last_replay_lsn()来检查滞后。

（以如何从此链接进行测量为例）

postgres=# SELECT now(), pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn(), EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp())::INT;
               now                | pg_last_wal_receive_lsn | pg_last_wal_replay_lsn | date_part 
----------------------------------+-------------------------+------------------------+-----------
 2018-08-06 07:00:36.540959+05:30 | 4/99B84030              | 4/99B84030             |       223

从第2列和第3列可以看出，最后的接收LSN和重放LSN是相同的，这意味着系统是同步的。但我无法理解到底是什么pg_last_xact_replay_timestamp()。它如何找出以秒为单位的复制延迟。我是否使用错误的方法来测量延迟（以秒为单位）？

免责声明:我已经阅读了关于堆栈溢出和互联网上的快照和版本控制主题的所有内容.我的要求不是审计跟踪或数据库级快照的版本跟踪.我花了一个多星期的时间自己研究并思考可能的选择.对不起,我可能错过了一些链接 - 如果我的问题的解决方案已在其他一些帖子中讨论过,请指出我.

它有点长; 请多多包涵.

下面是这样的情况:我们正在尝试创建一个通用设计,以在事务数据库中存储事务数据的快照,并保留参考数据的修订历史记录.

作为业务流程的一部分,用户可以按下按钮来发布某个对象.为了便于说明,我们假设用户可以在协商开始之前从供应商发布提案.然后,在通过协商过程的不同时间点,用户可以发布提议数据.该提案包含预算,销售目标和许多其他项目.快照提案时,必须为所有链接的实体创建快照.最后,在谈判之后签订合同.此时,必须创建合同的完整快照.并非合同中的所有实体都存在于提案中 - 存在大量重叠的实体,但提案和合同中附有唯一的实体.

我们必须保留这些已发布的版本和最新的活动版本.已发布的版本可在网站上获得,供供应商和管理团队参考.并非所有已发布的版本都在网站上提供,但最新发布的提案和最新发布的合同始终在网站上提供.该网站还必须从同一数据库填充.

此外,财务用户可以决定仅对预算进行快照,销售经理可以对销售目标进行快照.因此,快照可以多种粒度使用.

我们还需要跟踪主数据的版本.随着时间的推移跟踪关键主数据列的所有更改是业务要求.例如,我们有与销售目标相关的区域信息.该地区的名称可能会更改,我们希望跟踪这些更改.我们假设在提议时,区域的名称是R1,并创建快照.然后,该区域的名称将更改为R2,然后创建其他2个快照.我们希望能够在这些时间点将销售目标链接到正确的区域名称,而不一定是最新的区域名称.

我们在建模方面具有一定的灵活性,因为我们有一个事务数据库和一个数据仓库数据库,我们可以决定将这些信息存储在事务数据库或数据仓库数据库中.

这是我们的设计.我们有一个出版物表,其中包含有关已发布数据的基本信息 - 发布者以及发布对象的日期,原因和类型(提案或预算或销售目标).

我们将快照存储在与原始数据相同的表中.因此,提案快照将与提案表中的实时提案一起存储.我们在每个必须发布的表中都有一个名为Publication ID的列.此列是Publication表的FK.如果Publication ID为null,则该记录是活动版本.

我意识到这个帖子非常冗长.因此,我没有列出场景细节,而是想到在思维导图中快速总结设计注意事项.

现在有两个我们倾向于的解决方案 - 两者都会存储所有数据的快照,无论它是否已经改变.在保持表结构完整的同时仅保持增量将需要非常复杂的存储过程,该存储过程必须在任何快照对象的每次插入/更新时运行.我不想沿着这条路走下去,因为这需要更长的时间,而且音量也不是那么大.

解决方案1:每次发布一个对象(如提议或预算),我们将填充XML树并将其保留在数据库中.只需要在网站上提供最新版本,很少需要旧版本.鉴于此,由于使用XML,我是否会遇到大的性能问题？我们使用SQL Server.数据量并不大.

解决方案2:所有事务表都具有发布ID,参考数据将具有开始和结束日期.每当发布一个对象时,我们都会复制所有事务记录并将发布ID放在那里,我们将复制所有参考数据记录并将快照日期作为结束日期.这将允许我们在发布过程之外对参考数据进行正常版本控制.

我需要有经验的人士就这两种方法的缺点以及是否还有其他更好的方案提出意见.

我使用向导和T-SQL在SQL Server 2008中配置了一个发行版,但之后我想删除它使用向导(右键单击复制并选择"禁用发布和发布...")或执行以下命令:其参数:

exec sp_dropdistributor @no_checks = 1 -- no new results with @ignore_distributor = 1

将出现此错误:

Msq 21122,级别16,状态1,过程sp_dropdistributiondb第124行无法删除分发数据库'lobloblob',因为它当前正在使用中.

我没有发布任何东西,没有配置任何订阅但是给出了这个错误我该怎么办？

在一个应用程序中参考Django文档中的多个数据库的示例,

https://docs.djangoproject.com/en/dev/topics/db/multi-db/#an-example

"它也没有考虑事务与数据库利用策略的交互."

我如何处理上述交互.

场景是这样的:

我使用postgresql作为我的数据库.我已经设置了一个副本,并希望所有对"auth"表的读取都转到副本.根据文档,我写了一个数据库路由器.现在每当我尝试登录我的应用程序时都会抛出以下错误.

DatabaseError: cannot execute UPDATE in a read-only transaction.

当Django试图保存"last_login"时间时会发生这种情况.因为,在同一视图中,它首先从副本提取记录,然后尝试更新last_login时间.由于它发生在一个事务中,因此使用相同的数据库,即副本.

我该如何处理？

思考？

我们聘请了一名实习生,并希望让他利用我们的数据来生成有用的报告.目前我们只是创建了一个数据库快照并创建了一个我们授予他访问权限的新RDS实例.但由于生产数据库的变化,这几乎立即过时了.

我们想要的是我们实际数据库的实时(或接近实时)镜像,我们可以让他访问,而不必担心他修改任何真实数据或意外地关闭我们的生产数据库(例如通过运行愚蠢的查询喜欢SELECT (*) FROM ourbigtable或非常慢的加入).

只读复制品是否适用于此目的？看起来它至少会保持最新状态,但我不清楚如果读取副本发生故障或数据意外更改或任何其他潜在的负债会发生什么.

我能找到的唯一与此相关的是这个问题,这让我有点担心(强调我的):

如果您正在尝试预先计算大量数据并以其他方式修改只读副本上的内容,那么您需要非常小心,不要更改数据 - 如果读取不再一致,那么您就遇到了麻烦 :)

TL; DR不要这样做,除非你真的知道自己在做什么,并且了解所有后果.

而且直截了当地说,根据我的经验,MySQL复制可能是古怪的,所以即使知道应该发生什么,如果主人试图将更新的数据写入奴隶,你会更新......谁知道会发生什么.

如果我们让一个实习生在一个未引用的只读副本上有它,那么生产数据库是否有任何风险？

人们,我工作的公司在AWS(Amazon RDS)上有一些MySQL数据库.我们正在使用BigQuery制作POC,我现在正在研究的是如何将基础复制到BigQuery(现有的寄存器和未来的寄存器).我的怀疑是:

• 如何将MySQL表和行复制到BigQuery.有没有工具可以做到这一点(我正在阅读亚马逊数据库迁移服务)？我应该复制到Google Cloud SQL而不是导出到BigQuery吗？
• 如何复制未来的寄存器？可以在MySQL内部创建一个作业,在预定义的数字后发送新的寄存器吗？例如,在插入1,000个新行(或传递时间)之后,某些事件被"触发"并且新的寄存器被复制到Cloud SQL/BigQuery？

我最初的想法是转储原始基础,将其加载到另一个基础并使用脚本来监听新寄存器并将它们发送到新基础.

我有没有正确解释过？这可以理解吗？

我需要将数据从AWS RDS Postgres（9.6）数据库复制到本地Postgres（9.5）数据库。我发现了有关从本地复制到本地的内容。但是，我们如何才能将其实现到AWS RDS本地？

我们有一个仅插入表，由于使用嵌套循环而不是散列连接的查询计划，我们经常得到不好的结果。为了解决这个问题，我们必须手动运行 ANALYZE（真空有时不会在仅插入表上运行，长话短说，不是这里的重点）。当我尝试在副本机器上运行分析时，ERROR: cannot execute ANALYZE during recovery出现错误。所以这让我觉得我们可能不需要在副本上执行 ANALYZE。

我的问题是：在主节点上执行分析时统计信息是否传播到副本？

下面链接中的问题与此类似，但它是针对真空提出的。我们只使用 ANALYZE。 https://serverfault.com/questions/212219/postgresql-9-does-vacuuming-a-table-on-the-primary-replicate-on-the-mirror

我们使用主-主复制来避免写入副本会使其与真正的主服务器不同步以及我们希望切换主服务器的情况。然而，自动增量字段有一个看似已知的问题，它会导致“键‘主’的重复条目”，到目前为止我还没有找到好的解决方案，所以提出这个问题。

情况：两个主服务器都将 INSERT 语句插入到具有 AUTOINCREMENT 字段的表中。当它们同时 INSERT 时（是的，发生了......）并且因此具有相同的编号，它们最终都无法从另一个主服务器启动该语句并使复制过程停止。

似乎这个问题很常见，只是我发现的当前解决方案似乎不够。

首先，假设特定行并不重要，这是发生这种情况时在两台服务器上启动的补救措施

STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE; SELECT sleep(0.5); SHOW SLAVE STATUS\G\

这可以根据需要多次启动，以确保所有这些错误都得到解决。

https://mariadb.com/kb/en/auto_increment/#replication的另一个建议解决方案是

为了使 master-master 或 Galera 安全地使用 AUTO_INCRMENT，应该使用系统变量 auto_increment_increment 和 auto_increment_offset 为每个服务器生成唯一的值。

问题是此设置虽然在所有表中创建“洞”，但不使用顺序 ID。

对于这种情况是否有更好的解决方案，例如“重复执行某事”？

查看https://mariadb.com/kb/en/binary-log-formats/我也很好奇为什么 MIXED 模式不认为这些 INSERT 语句不安全，尽管它们显然是……