标签: high-availability

在进入“NoSQL”领域多年之后，现在我遇到了一个本质上非常“关系”的问题。今天，我看到数据存储的眼光与以前截然不同。像 Riak 这样的事情已经让我无法忍受单点故障，“停机维护”等。当然，（或者我希望），我还没有完全失去理智。这是一个个人项目，还没有（或尚未）具有极高的要求。

大多数分片解决方案都没有给我我想要的（至少是一瞥），可能是因为我的问题很“容易”解决。至少在概念层面上（忽略 RDBM 本身带来的限制）。

1. 我有少量“共享”数据，可以自由复制。它没有硬一致性的要求。这可以存储在类似发电机的数据库中，并且可以无限扩展。但如果可能的话，我仍然希望使用单个数据库。

2. 我有很多“每用户”数据。也就是说 - 大量用户，每个用户都拥有绝对合理大小的数据，真正适合存储在单个 PostgreSQL 节点上。我们正在谈论最多 10 万条记录。

3. 我从不需要跨用户查询，也不需要跨用户原子性。

这听起来非常容易实现。至少当我用我的“NoSQL 眼睛”看它时。

以下是我幼稚的入门想法：

1. 在极端情况下，我可以将整个用户序列化为 Riak 中的单个键/值。当然，持续对几兆字节数据进行反/序列化会很慢，这就是我考虑使用 PostgreSQL 的原因。许多 Riak K/Vs 是行不通的，因为我需要每个用户数据中的原子性/事务。

2. 我可以为每个用户使用一个 SQLite 数据库，并使用 GlusterFS 之类的东西来实现冗余/可用性。如果我无法使用 PostgreSQL 找到同样好的东西，这可能是我要选择的解决方案。优点：可以很好地缩小/放大；缺点：我更喜欢 PostgreSQL 的类型和严格性而不是 SQLite

所以，我最好从 PostgreSQL 分片解决方案中要求：

1. 自动保留每个用户数据的多个副本（在不同的机器上）。能够为每个用户/分片动态切换主节点（如果之前的主节点出现故障）。
2. 能够通过添加/删除服务器节点动态扩大/缩小规模。大多数情况下，Riak 都能做到。
3. 不需要我的应用程序知道要与哪些节点以及何时进行通信。

当我们即将更改 5TB 数据库中的一些大表时，我发现自己需要一份可以在线执行的操作列表，这些操作需要在运行时保持全锁。理想情况下，该列表还包含有关哪些语句需要 SCH-M 锁在最后提交的信息。

虽然我在 Microsoft 的时候就认识了其中的大部分，但我很惊讶我找不到公开可用的在线操作列表，因为它们从 SQL Server 2005 一直发展到 2014 CTP。

有人有这样的清单吗？如果没有，我可能会决定创建它。

我有多个用于 Web 应用程序的 PostgreSQL 服务器。通常在热备模式（异步流复制）下一个主多从。

我使用 PGBouncer 进行连接池：安装在每个 PG 服务器（端口 6432）上的一个实例连接到本地主机上的数据库。我使用事务池模式。

为了在从站上平衡我的只读连接，我使用 HAProxy (v1.5) 和 conf 或多或少像这样：

listen pgsql_pool 0.0.0.0:10001
        mode tcp
        option pgsql-check user ha
        balance roundrobin
        server master 10.0.0.1:6432 check backup
        server slave1 10.0.0.2:6432 check
        server slave2 10.0.0.3:6432 check
        server slave3 10.0.0.4:6432 check

因此，我的 Web 应用程序连接到 haproxy（端口 10001），即在每个 PG 从站上配置的多个 pgbouncer 上的负载平衡连接。

这是我当前架构的表示图：

这很有效，但我意识到有些人的实现方式完全不同：Web 应用程序连接到单个 PGBouncer 实例，该实例连接到 HAproxy，它在多个 PG 服务器上进行负载平衡：

最好的方法是什么？第一个（我现在的）还是第二个？一种解决方案相对于另一种解决方案有什么优势吗？

谢谢

我做了一些谷歌搜索，但在几年前找不到这个问题的答案，所以我想我会问。Oracle 的 RAC 特性为读取和写入事务提供负载平衡，以及无需停机的横向扩展和高可用性（至少，据我所知 - 我们即将部署我们的第一个使用 RAC 的数据库，所以我们会看看情况如何）。

是否有提供等效功能的任何 SQL Server 功能集（或您可以安装在顶部的第三方组件）？我们一直使用 Windows 集群，其中故障转移事件会导致大约 20-30 秒的 SQL 停机时间 - 总是可以容忍的，但并不理想。现在，使用 SQL 2012 中的 AlwaysOn，SQL Server 将其缩短到大约 15 秒，并添加了只读辅助数据库的概念，但它们仍然要求通过单个连接点阻塞写入事务（大大改进，因为许多事务是只是阅读，但仍然不是真正的负载平衡），并且在节点故障或需要修补的情况下，仍然存在停机时间。

我想这只是更多的好奇心 - 我觉得这是 SQL Server 落后于 Oracle 的唯一领域（至少在我个人看到使用的功能中）。我想看看是否有任何选项可以缩小这一差距，并在我们等待添加 Microsoft 的等效功能的同时改进我们自己的 SQL Server 部署 - 也许在 SQL 2014/2015 中？

我的组织正计划采用 SQL Server 2012 可用性组，我正在尝试了解它将对我们的应用程序升级过程产生什么影响（如果有）。

我们每 8 周发布一次应用程序更新，任何发布都可能包括架构更改和/或数据迁移。

我想了解的是 HA/DR 解决方案是否透明地处理架构更改（新列、索引被添加到辅助节点），或者是否需要手动干预在每个实例上创建架构然后重新打开 Always On。

我假设的数据迁移部分是透明处理的，但也想确认一下。

我想我也做了一个笼统的假设，即基于可用性组配置的这些行为没有区别，这也可能是错误的。请告诉我。

简而言之; 在我的应用程序的任何给定版本中，我可能会通过向其中添加列来更改非常大的表（数百万条记录的数十到数百条记录）。某些列可能是“全新的”，因此它们可以使用 Enterprise Online 架构更改功能。其他列可能是现有列的重构（全名被拆分为名字和姓氏），并且将为表中的每一行运行迁移以填充这些字段。这些行为中的任何一个是否需要 DBA 更改 AlwaysOn 配置，或者这是默认处理的，并且所有辅助节点都“免费”获得 DDL 和 DML 语句？

感谢您提供的任何清晰度。

SQL Server的数据库镜像功能即将消失：

此功能将在 Microsoft SQL Server 的未来版本中删除。避免在新的开发工作中使用此功能，并计划修改当前使用此功能的应用程序。请改用AlwaysOn 可用性组。

有谁知道什么时候？高可用性（和快速恢复）数据库有哪些选择？

镜像和故障转移群集之间的主要区别是什么？

每个人解决什么样的问题，在什么样的场景中推荐每个人？

这是我第一次在 AWS 上使用 RDS，我使用 t2.medium 实例运行 MySQL Aurora 和默认配置。CPU 使用率和 DB 连接是很正常的，直到“某事”发生，这导致 DB 连接一直达到最大值（t2.medium 为 80 个连接）。

我只有一个 Web 应用程序，在 EC2 实例上运行。当数据库连接数达到最大值时，EC2 实例的 CPU 使用率绝对正常（25-30%），但所有尝试连接到数据库实例的结果都是“连接过多”。

我当时还检查了数据库实例的 CPU 利用率 - 它没有显示高负载信号。在罢工期间，CPU 利用率下降到 20% 并始终保持该比率。

我不明白的事情：数据库连接已达到最大值，但为什么数据库 CPU 利用率下降了？由于这些连接中的查询计算，它不应该也处于最大值吗？

请帮助我理解，非常感谢。

（当第二次罢工发生时，我不得不将 RDS 实例的大小调整为 r4.large；我现在仍在运行它，直到我发现问题......）

我是 PostgreSQL 数据库的新手。最近我们的开发人员需要对我们的系统进行一些升级。

因此，我们计划实施一些方法来实现数据库故障转移。

根据我在此处阅读 postgresql wiki ，我们正在尝试实现热备用或热备用。所以我的问题是：

1. 它们之间的主要区别是什么？
2. 哪一个更好？
3. 有没有其他方法可以考虑在我们的 Postgres 数据库中实现高可用性？

首先我不得不说这个问题来自软件工程师的角度。不幸的是，我们没有 DBA，所以我们需要管理我们自己的数据库。

我们安装了 SQL Server 2012 Enterprise 来运行一个应该 24/7 可用的数据库。数据库大约 150 GB，一些表包含数十亿行。多个服务每分钟访问数据库数千次，以插入实时测量数据。所以当数据库宕机半小时，测量数据丢失半小时，这是我们承受不起的……

在这种情况下，我们有两个主要问题：

1. 我们何时以及如何安装 Microsoft 更新？
2. 我们如何应用架构更改？

我认为 Windows 更新不需要进一步解释。当新需求出现或现有需求发生变化时，我们有时需要进行一些架构更改。例如添加一些额外的列、更改数据类型、调整 varchar 字段的大小等。其中一些更改需要很长时间才能运行，甚至超时，因为数据库始终处于高负载下。

我们正在考虑安装一个额外的实例并启用 AlwaysOn，以完成以下操作：

1. 对于 Windows 更新，关闭一台服务器，安装 Windows 更新，重新启动，然后更新第二个实例。
2. 对于架构更改，关闭一台服务器，应用架构更改，将其恢复，然后将相同的更改应用于第二个实例。

这两件事可以通过 SQL Server AlwaysOn 来完成，这是一种常见的方法吗？数据甚至会在之后同步吗？还是我完全在考虑错误的方向，是否有更好的解决方案？