标签: standby

我正在为两个数据库 db1 和 db2 创建日志传送。

它将从 SQL Server 2008 R2 升级到更新的版本 SQL Server 2012。

在 SQL Server 2008R2 上，它们都是dbi_version= 661：

DBCC TRACEON (3604);  
GO 
DBCC PAGE (db1, 1, 9, 3); 
GO 
DBCC TRACEOFF (3604); 

我在待机模式下恢复它们：

RESTORE DATABASE db1 FROM DISK = 'Q:\db1.bak' WITH STANDBY = N'R:\SQLLog\db1.undo'

其中一个恢复正常，升级，另一个给我错误：

由于需要升级数据库，因此无法使用 WITH STANDBY 恢复此备份。在没有 WITH STANDBY 的情况下重新发出 RESTORE。

如果“备用文件”丢失，有没有办法从备用/只读模式恢复 SQL 数据库？

（我看到一些参考文献在日志传送场景中将其称为 TUF 文件，但在我的情况下，它只是手动还原，备用文件具有 BAK 扩展名。）

执行“RESTORE DATABASE foo WITH RECOVERY”会导致致命错误：

During startup of warm standby database 'foo', its standby file
('path\filename.bak') was inaccessible to the RESTORE statement.
The operating system error was '5(Access is denied.)'. Diagnose the
operating system error, correct the problem, and retry startup.

恢复是前一段时间完成的，不幸的是备用文件在备份文件夹中，并被我们的文件夹清理程序删除了。任何其他媒体上都不存在该文件的副本。用于恢复到这一点的原始备份也早已不复存在。

幸运的是，这对我们来说没什么大不了的（这是一个临时恢复），但是除了“不要删除该文件”之外，我找不到关于这个问题的任何其他有用的参考资料。

如果归根结底，我想我可以编写整个数据库的脚本，或者使用 SSIS 将所有对象复制到新的数据库容器中，因为我面前有一个 db 的只读副本。

有什么办法可以解决这个问题？我当然不希望我能够将它翻转回“恢复”并继续进行后续的恢复或任何事情，我只想在当前状态下将其强制进入正常的在线模式，以便我可以做到诸如更改权限、更改恢复模式或进行新的完整备份之类的事情。

我想将我的数据库实例从 AWS RDS MySQL 迁移到 Aurora，但我对复制以及 Aurora 如何管理写入/读取操作有疑问。

我有我的应用程序，我想将写入操作与读取操作分开。我想创建一个仅用于写操作的主实例，而其他实例（只读副本）仅用于读操作。

问题就在这里，我在 AWS 文档上读到我需要在我的应用程序上进行这种分离，我认为或者我希望找到一种方法来做到这一点并对我的应用程序透明。我画了一个简单的模式，我必须做什么才能使用 Aurora（来自 AWS）：

AWS 所说的我必须做什么：

      -----------------
      |  Application  |
      -----------------
       |             |
       | writes      |reads      
       |             |
------------      ------------------
|  Master  |      |  Read Replica  |
------------      ------------------
       ^            ^
       |replication |
       |____________|

我需要什么：

我需要 Master 始终保持写入操作，并将读取重定向到只读副本实例。

      -----------------
      |  Application  |
      -----------------
       |
       |write/read
       |           
------------   Reads    ------------------
|  Master  | <------->  |  Read Replica  |
------------            ------------------
       ^                     ^
       |      replication    | …

我的设置看起来像这样：我有一个主服务器（Postgres 9.6），它不断地从网络上抓取大量数据。我希望能够将表或数据库的子集从该主实例流式传输到辅助实例，以便我可以从 Web 应用程序读取数据。Web 应用程序需要对其数据库执行标准的 Web 应用程序操作（用户帐户的读/写表、执行身份验证等），并且还能够对复制的数据运行查询。

带有热备用的流式复制看起来很适合我，但是几年前的 Reddit 响应似乎表明您根本无法过滤特定表或写入复制的集群。通过在互联网上闲逛，我的印象是大多数人使用 Bucardo 和 Slony 等第三方工具解决这个问题——我对此持开放态度，但我正在寻找最简单的解决方案，并添加一个专用的复制系统来解决这个问题。我的筹码似乎不必要地紧张。去年的这个 SO 问题在使用逻辑解码方面取得了有希望的领先优势，这让我想知道在这个方向上是否有任何新的工作。我还想知道只运行两个 Postgres 实例并将它们绑定到不同的端口是否可行。

这里有不需要安装第三方工具的解决方案吗？如果绝对需要第三方工具，根据您的经验，哪一个工具的开销最低？

在此先感谢大家的帮助。第一个问题在这里，我很高兴能够获得您的专业知识。

我正在尝试 postgres-addon citus。到目前为止，我已经设置了一个包含一个协调器和三个工作节点的集群。

现在我想为其中一个工作节点设置辅助节点。到目前为止，我已经设置了从该工作节点到第四个（备用）节点的流复制。

我现在是否必须使用add_node和 noderole“辅助”将备用节点添加为辅助节点？

citus_add_secondary_node更好，因为您必须使用该命令定义合适的主节点？

或者，设置一个带有 citus 扩展的新数据库就足够了，并且add_node/ secondary会将该节点转变为包含来自工作线程的所有数据的辅助节点？

我使用以下命令获得了辅助节点的正确组 ID：

select * from pg_dist_node;

我正在尝试提出一种使用“备用”还原模式跟上每日数据库更新过程的策略。

我从第三方的 FTP 站点获取 24 个日志传送文件（用于前一天的每小时事务日志文件）。我会在每晚运行时更新这 24 个文件。我最初以 SQB 文件格式获取这些文件，然后我有一个工具和脚本将这些 SQB 文件转换为 BAK 文件格式。

现在，我正在尝试制定一个持续备份计划的策略。

数据库不必更新或修改，只需读取即可。 我是否始终将每个事务日志文件恢复为“备用”，而将它们保留为“备用”模式？

我计划创建一个单独的数据库，以便仅从这个“只读”数据库的某些表中检索必要的数据。

我还有一个问题。如果我不小心运行脚本将此数据库恢复为“NoRecovery or Recovery”模式，有没有办法通过运行脚本将模式更改回“Standby”，或者我是否必须再次将完整的 bak 文件恢复为“Standby”（做整个过程再次）？

我已经使用数据代理配置了数据保护设置。当我向主数据库中的表插入新数据时，该数据应该反映在备用数据库中。当我检查备用数据库中的这些数据时，它没有反映在那里。所以，我重新启动了数据库并以只读方式打开它。我使用以下命令来避免延迟：

SQL> alter database recover managed standby database nodelay disconnect from session;

但是仍然需要很多时间才能在备用数据库中反映出来。

将数据从主服务器获取到备用服务器所花费的时间延迟是多少？

这是数据反映在备用数据库中所花费的标准时间延迟吗？或者我是否错过了配置中的任何内容。

有什么办法可以解决吗？