标签: aws

我们现在在处理高峰时段服务器的密集流量时遇到问题；请参阅有关调整 DB 的相关问题。目前，我们正在使用较小的云服务作为服务器托管。目前，我们正在研究将我们的服务器迁移到 AWS 的可能性。我们遇到的问题主要与我们的数据库服务器有关，因此我们希望拥有比我们现在使用的要好得多的 AWS 实例。

数据库服务器所在云服务器的统计信息如下：

• 8核
• 16GB 内存
• 100 GB，RAID-10 * SAS 15.000 RPM

在选择用于 PostgreSQL 数据库服务器的亚马逊实例时，您有什么特别需要考虑的吗？

我有一个 MySQL RDS 实例（“生产”），我需要从中将增量数据复制到另一个 MySQL RDS 实例（“报告”）。“增量数据”是某些表中的新行。目前，我通过一个 PHP 脚本完成此操作，该脚本根据上次更新时间从“生产”查询并将 CSV 文件写入磁盘，然后使用 mysqlimport.exe 将文件导入“报告”。

我目前的方法需要大约 80 秒。这是最强大和最有效的方法吗？我找到了其他用于“一次性”传输的工具，但没有找到“企业增量数据库复制”工具。

由于报告端的批处理操作，我们当前的过程不是“连续”复制。不过这可能是可以协商的。放松这种限制会打开工具，使这变得容易吗？

相关相关文章/问题：亚马逊关于导入数据的文章好像主要是处理批处理（初始加载）的情况。 http://aws.amazon.com/articles/2933

当在同一实例上从一个数据库移动到另一个数据库时，这可以通过存储过程来完成（我的问题是它们是不同的实例）。请参阅：保持 MySQL 暂存数据库在同一台服务器上从生产更新
我不能将两个数据库放在同一个实例上，因为我们的实例负载相当大。

我正在使用他们的 DMS 工具将我的数据库迁移到 Amazon 的 RDS。除了在源数据库上标记为 auto_increment 的列没有在目标数据库上标记为 auto_increment 之外，几乎所有内容看起来都不错。我还注意到我的索引和外键约束不包括在内。我在两端都运行 5.6 版。

有没有办法让 DMS 包含我的数据库的完整创建表？

我刚刚开始测试 AWS Redshift 并使用AWS 示例数据填充单个节点。

查询包含 10 行或约 400 行的表大约需要 2 秒（未缓存）。

我不确定我是否误解了什么，但我认为这会快得多。我在这里缺少什么吗？

谢谢！任何反馈表示赞赏。

我正在尝试在表中添加一个新列，并且查询给了我这个错误 1114。

我的 RDS 实例大小很小。1.7 GB 内存，1 个 ECU（1 个虚拟核心和 1 个 ECU）我试图修改的表有 500 万行和 7GB 的大小。实例的磁盘大小为 15GB（40% 免费）。

这对我们来说是关键时刻，因为我们被卡住了，AWS RDS 不允许访问 mysql 配置的所有参数。我如何摆脱这个问题？

我有一个 Amazon RDS Postgres 数据库，我创建了一个“复制器”用户并授予它“复制”权限。

db=> create role replicator login password 'something';
CREATE ROLE
db=> alter role replicator replication;
ALTER ROLE
db=>

但是，当我尝试pg_basebackup从目标主机运行以创建副本时，出现 pg_hba.conf 错误：

# pg_basebackup -D /data/from-master -U replicator -h db-master.example.com -v
pg_basebackup: could not connect to server: FATAL:  no pg_hba.conf entry for replication connection from host "10.1.20.19", user "replicator", SSL on
FATAL:  no pg_hba.conf entry for replication connection from host "10.1.20.19", user "replicator", SSL off

问题是，这是 RDS，我根本无法访问 pg_hba.conf。有任何想法吗？

所以我对 AWS 还很陌生，我希望你们可以让我放心，因为我在 AWS 文档中找不到任何内容。其实我有两个问题，第一个：

我在 AWS 中有一个 RDS MySql 实例，它不是我自己设置的（以前的员工这样做了）。这个实例比我们需要的更强大，所以我想减少它的实例类以降低成本。当前实例是多可用区配置。

1. 我可以简单地更改它并在下一次维护计划中应用更改而不会丢失数据吗？

2. 如何确定当前使用了多少 RDS 存储？如果可能的话，我想减少它，因为我们甚至没有使用它的 50%。

我有 2 个 AWS RDS 数据库（A 和 B），需要在 AWS 中创建一个具有星型方案和缓慢变化维度的数据仓库。

从 MS 背景来看，创建一个 SSIS 包作为 SQL 作业运行是有意义的，它可以整理 A 和 B 数据库并创建维度和事实。

AWS RDS 没有 SSIS 支持，因此我需要运行一个安装了 SQL Server 的 EC2 实例，然后运行 ​​SSIS 包。

我的问题是 - 有没有更好的方法，假设一个沉重的 MS 堆栈和 AWS？

在我的 MongoDB 日志中，我看到以下消息行：

2016-04-05T00:03:42.904+0000 I COMMAND  [ftdc] serverStatus was very slow: { after basic: 200, after asserts: 240, after backgroundFlushing: 380, after connections: 510, after dur: 650, after extra_info: 930, after globalLock: 1070, after locks: 1190, after network: 1270, after opcounters: 1310, after opcountersRepl: 1310, after storageEngine: 1430, after tcmalloc: 1620, at end: 2900 }
2016-04-05T00:03:49.910+0000 I COMMAND  [ftdc] serverStatus was very slow: { after basic: 160, after asserts: 220, after backgroundFlushing: 390, after connections: 580, after dur: 670, after …

我们一直在维护一个具有网络和移动应用程序平台的项目。该项目的后端使用Django 1.10开发并部署在AWS中。

一开始，当用户很少时，我们使用一个 EC2 实例和一个带有 PostgreSQL 数据库的 RDS 实例进行部署。一段时间后，用户数量增加，我们遇到了响应速度很慢、不同页面超时等问题。由于性能问题，我们采取了以下措施：

• 我们开始使用 Redis 缓存来存储频繁访问的数据（AWS 中的 ElasticCache）
• 我们部署在两个不同的 EC2 实例中（一个用于 Web 平台，另一个用于移动应用程序的 API）。
• 我们在RDS中创建了一个只读副本，并添加了一个数据库路由器，该路由器选择仅使用主数据库进行写入操作，所有读取操作都在只读副本数据库中执行。

该解决方案在短短几周内运行良好。一段时间后，所有读取操作都变得太慢。此时，与主数据库的数据库连接数量平均为 2-3 个，有时会激增至 5-7 个。但由于只读副本数据库中的查询执行速度较慢，30-50 个连接在只读副本数据库中很常见。

使用 JOIN 和聚合的查询经常失败，并在只读副本中出现以下错误：

canceling statement due to conflict with recovery DETAIL: User query might have needed to see row versions that must be removed.

但与主数据库相比，只读副本中的所有查询通常都非常慢，即使是最简单的 SELECT 查询也是如此。

为了确保问题不在于特定的只读副本实例，我们创建了另一个只读副本 RDS 实例（例如 read-replica-2）并将所有读取操作指向 read-replica-2 DB。此配置一开始表现良好，但一天内性能显着下降（对于第一个只读副本，需要 3-4 周）。

之后，我们修改了数据库路由器，以针对任何读取操作随机达到只读副本和只读副本 2 之一的峰值，但对这两个只读副本数据库的所有查询执行速度仍然非常慢。我们通过将读操作切换到master数据库进行检查，相同的读操作在master数据库中执行顺利，没有任何问题。

一些服务器负载相关信息：

• 在高峰时段，有 500-1000 个用户使用该系统，其中大多数来自移动应用程序（通过 API EC2 实例）。
• 在高峰时段，访问Web平台的用户很少。但它们经常执行繁重的数据库密集型任务（例如批量导入和导出数据）。
• 在非高峰时段（当地夜间的 6 小时窗口内），系统中会执行一些繁重的数据库密集型 cron 作业，以进行报告生成和维护。

考虑到这种情况，适合我们的架构应该是什么？我们是否遗漏了一些明显的东西？什么会导致相同的查询在 RDS …