标签: failover

MySql 数据库即服务：

1. 亚马逊
2. 泽润

另一个例如。PostgreSQL 数据库即服务。您可以在此处获取类似产品的列表。

有没有人详细了解这些 DbaaS 的性能、可靠性和可扩展性？阅读有关这些产品的文献会使它们听起来好得令人难以置信。我内心的愤世嫉俗感告诉我要质疑这些说法。

• 我尝试向 SQL Server（2012 标准）故障转移添加一个新节点，该节点已安装在 Windows2012 故障转移群集的另一个节点上
• 我在输入 SQL Server 代理帐户名称时遇到不可编辑字段的问题
• 可能有与 SQL Server 数据库引擎 (ei) 相同的 AD 名称
• 我的帐户访问权限没有 AD 管理员权限
• 父节点上 SQL Server Agent 的访问、帐户和设置是可访问和可设置的

我的公司有一对 SQL Server 2005 实例的故障转移对，它们为 UL 许可的警报/呼叫中心提供数据库可用性，其中正常运行时间和可用性对生命安全至关重要。

下面是来自其中一个关键业务应用程序的 connectionStrings 的示例行（为了我们的保护而进行了消毒）：

<add name="MyCompany.MyApp.Properties.Settings.MyDbConnectionString"
 connectionString="Data Source=Principal-DB;Failover Partner=Mirror-DB;
 Initial Catalog=MyDb; Integrated Security=True; Persist Security Info=True;"
 providerName="System.Data.SqlClient" />

大约半小时前，这是我们认为的场景：

1. DBA 在指定时间向所有用户报告 Principal-DB 服务器上的硬件维护需求，并建议他们在遇到数据库连接问题时关闭并重新启动客户端应用程序。
2. DBA 从主体数据库故障转移到镜像数据库。客户端应用程序不受影响。
3. DBA 关闭 Principal-DB 服务器。
4. 某些客户端应用程序开始在池连接上超时（正如预期的那样）。遇到这些错误的用户按照 DBA 的建议关闭并重新启动。
5. 由于无法从数据库接收响应，这些客户端应用程序现在无法完全启动。
6. 欢闹随之而来。

我们的理论是，因为主要-DB不在状态，以响应连接请求在所有的，当它通常会迅速地拒绝这样的连接，如果它是在恢复状态，客户端应用程序结束了等待整个分配连接超时（默认为 20 秒）让主服务器响应，然后返回超时错误，而无需尝试连接到列出的故障转移伙伴。

快速修复是将更新推送到包含交换数据源和故障转移伙伴实例的 App.config 的客户端应用程序，因此 Mirror-DB 现在是应用程序首先尝试连接的服务器。当我们故障恢复到 Principal-DB 时，我们将不得不使用另一个应用程序更新来撤消此更改。

我需要一个更永久的修复。这不是故障转移对的预期行为，并且不允许再次发生。必须有一种方法来配置客户端应用程序，以便它在返回错误之前在这种情况下正确尝试连接到故障转移伙伴。

当镜像伙伴关闭时，在故障转移后收到下面提到的错误。

错误 ：

故障转移到未配置为数据库镜像的数据库。代码：22037，文本：'无效的连接字符串属性无法打开登录请求的数据库“DBName”。登录失败。用户“域\用户”登录失败。连接尝试故障转移到未配置数据库镜像的数据库。

设想 ：

1. X 是主体服务器，Y 是 X 的镜像伙伴
2. X 也是发布者，Z 也是分发服务器
3. 在 X 和 Y 服务器中添加 Z 作为分发服务器。X 和 Y 也添加为 Z 服务器中的发布者
4. 在复制日志读取器代理配置文件设置中将 Y 配置为“PublisherFailoverPartner”
5. X 的故障转移
6. 此后Y成为委托人，X成为镜像合伙人
7. 将镜像从 Y 中断到 X 或 X 服务器已关闭且不可用

执行上述步骤后，复制开始抛出错误。当镜像打开时，复制正在工作，否则会引发提到的错误。

你能建议我解决它的步骤吗？

我对 postgres 9.1 复制机制完全陌生。

我已经设法在主 postgres 和备用 postgres 之间设置流复制（两者都有 x 条记录）。当主服务器发生故障时，备用服务器会使用触发文件机制接管，并积累额外的数据（假设现在有 x+y 条记录）。

现在，当原始主服务器出现时，它仍然有 x 条记录（现在是新的主服务器）。有没有办法只获取增量，即从备用数据库中新添加的“y”条记录并作为主数据库重新启动。

或者我必须始终进行整个基地备份？

我已成功使用GTID_MODE. 它完美地工作。现在我需要在其中设置自动故障转移功能。我已经运行了以下命令。

mysqlfailover --master=root:abc@10.24.184.12:3306 --discover-slaves-login=root:abc

我得到了以下结果。没有列出任何奴隶。

MySQL Replication Failover Utility
Failover Mode = auto     Next Interval = Tue May

Master Information
------------------
Binary Log File   Position  Binlog_Do_DB  Binlog
mysql-bin.000016  9568

GTID Executed Set
8fe8b710-cd34-11e4-824d-fa163e52e544:1-1143

Replication Health Status
0 Rows Found.
Q-quit R-refresh H-health G-GTID Lists U-UUIDs U

但是当我执行mysqlrplcheck和mysqlrplshow命令时，会列出从属设备。

这是正常的吗？

在 2 节点 Windows Server 故障转移群集配置中，如何重新启动 SQL Server 服务而不故障转移到其他节点？

我们有一个主动/被动拓扑，其中有两个共享原始存储的 x86 复合体，其中在给定时刻只有一个节点可以访问共享存储（也称为主动节点）。如果主动节点发生故障转移，被动节点将启动接管并成为可以访问共享存储的主动节点。每个节点都有自己的带有文件系统的引导设备存储。但是，共享存储上不能安装文件系统。

我们有兴趣在两个节点上安装 MySQL，它的数据驻留在共享存储中，只有活动节点运行服务器。

带有 InnoDB 的 MySQL 能够在原始设备上运行，并且还有关于如何在类似于我们的拓扑的集群上运行MySQL的指南。但是，在第二个示例中，它们确实在共享存储上安装了一个文件系统。文件系统问题引起了一个主要问题：

ib_logfile* 仍然需要一个文件系统。所以原始的 MySQL 功能并不完全是原始的。如果我错了，请纠正我。是否有将这些文件存储在原始存储中的解决方法？我们可以将重做日志 ( ib_logfile0, ib_logfile1)保存在节点的引导设备中，并始终在服务器启动之前删除这些文件（因此在多次故障转移的情况下我们不会有旧的日志文件）。但是，这可能会导致未提交的事务在事务中间失败的情况下被部分提交，从而与事务的整体思想相矛盾。

在此拓扑中，是否还有其他文件/功能可能会影响 mysql 的行为？

我对 SQL Server 的主动/主动集群有一个模糊的理解。任何人都可以帮助确认我的理解是否正确？

据我了解，主动/主动集群使用两个或多个 Windows 服务器。假设我们有两台服务器 n1 和 n2。然后我们在这两台服务器上创建一个故障转移集群，并将 n1 和 n2 加入集群。然后我们在 n1 和 n2 上安装一个 SQL Server 实例 i1。之后，我们在 n1 和 n2 上安装另一个 SQL Server 实例 i2。然后我们可以在 n1 上启动 i1 并在 n2 上启动 i2 以创建一个主动/主动集群。稍后我们可以将 i1 从 n1 故障转移到 n2，并将 i2 从 n2 故障转移到 n1。

我的理解正确吗？我们是否需要在 n1 和 n2 上安装实例 i1 和 i2？安装配置好主动/主动集群后，每个节点上安装并运行了多少SQL Server服务？

让我们考虑在异步复制中有两个节点的 SQL Server AlwaysOn 群集。
有没有办法计算强制故障转移后丢失了多少数据？

我的意思是在时间方面，能够知道“我丢失了 1 小时的数据或 1 分钟”。我考虑过检查 LSN，但我不知道如何将它们转换为日期时间。