标签: aws-aurora

我想弄清楚为什么一个UPDATE语句需要太长时间（> 30 秒）。

这是随机的，即在大多数情况下，它在 100 毫秒内完成。但是，有时（随机）需要> 30 秒才能完成。

一些细节：

• 我使用的是 PostgreSQL 12（实际上是 AWS Aurora）
• 我正在一个没有流量的数据库中尝试这个，所以它不会受到同时运行的任何其他查询的影响。我也在监视日志以查看是否还有其他内容正在运行，但我什么也没看到。
• 我试过REINDEXing、VACUUMing（和VACUUM ANALYZE），但没有任何改进
• 我检查了锁，( log_lock_waits) 但我什么也没看到。
• 查询在循环中执行（来自 Python 应用程序）。它执行大约 5000 次查询，在某些时候，其中一些查询似乎没有遵循某种模式，需要花费大量时间才能完成。
• 我试过分批运行它们，但同样，有些批次随机运行时间太长。
• 表的大小有点大，约 10000000 行和约 25 个索引。

查询：

UPDATE "my_table" SET "match_request_id" = 'c607789f-4816-4a38-844b-173fa7bf64ed'::uuid WHERE "my_table"."id" = 129624354;

的输出 EXPLAIN (ANALYZE VERBOSE BUFFERS COSTS)

 Update on public.my_table  (cost=0.56..8.58 rows=1 width=832) (actual time=34106.965..34106.966 rows=0 loops=1)
   Buffers: shared hit=431280 read=27724
   I/O Timings: read=32469.021
   ->  Index Scan using my_table_pkey on …

使用Amazon Aurora Postgres 2.0 版，它基本上是带有修改过的存储层的 PostgreSQL 10.4。

尝试恢复包含多行的转储，如：

ALTER FUNCTION myschema.f_myfunc(anyarray, anyelement) OWNER TO myrole;

我收到每一个ALTER FUNCTION这样的错误消息：

ERROR:  improper qualified name (too many dotted names)

Run Code Online (Sandbox Code Playgroud)

在 psql 中尝试相同的方法会产生相同的错误。即使是最简单的形式：

ALTER FUNCTION foo() OWNER TO myrole;

没有点名。我在这里发现了类似的抱怨：https : //forums.aws.amazon.com/thread.jspa?messageID=872096&tstart=0

一定是 Aurora 中的错误 - 还是我遗漏了什么？

目前的情况

我们目前正在研究一种新产品，它将设备数据发送回给我们进行解释。

这些是我们正在查看的数字：

• 设备很可能每 5 分钟发送一次数据
• 到明年年底将有 26.000 台设备
  • 每 5 分钟 26.000 次插入。我们很可能几乎无法控制间隔，因此这 26.000 个 INSERTS 很可能不会均匀分布在这 5 分钟内。
  • ~ 每年 2.733.120.000 条数据条目
• 每个数据包都将采用 JSON 格式，大小在 300 - 500 字节之间。
• 我们预计每年会有大约 8.000 台新设备。

我们目前为我们的内部系统管理多个数据库，但对此类卷几乎没有经验。我们现在使用 AWS Aurora，理论上应该支持 100.000 个插入 p/s。

这些数据将如何使用？

这些数据将主要用于在我们的客户门户中创建报告：

• 设备指标的实时报告
• 历史报告，IE：
  • 2019 年 2 月 2 日的设备统计数据如何？
  • 第 12 周是什么样的？
  • 给我一个 1 月份指标的摘要
  • 显示特定列总和的图表，按月分组

问题

老实说，考虑到我对这样的数据量没有任何实际操作经验，我发现很难做出可靠的选择。

我们目前的堆栈

我们结合使用 AWS EC2 机器和 AWS Aurora 集群来管理我们的数据。理想的解决方案是面向 AWS 的。

我正在考虑的基础设施：

选项 #1：为了简单起见，将所有内容直接存储到 Aurora 可能是一个不错的解决方案。

选项#2：但是，为了分离我们的“实时”数据和解释数据，也许这样的事情会更好。

实际问题

• 一个兼容 MySQL …

我们的 AWS Aurora MySQL 实例出现可用内存不足并因此崩溃的问题。AWS的回应是升级到更大的实例，但我认为这不一定能解决问题。

我们使用的是 db.r5.large 实例，内存为 15GB。

重新启动后，RAM 会下降到 5GB，这几乎是预料之中的，但随后在一周内逐渐下降到 0GB RAM，然后重新启动 - 有时会失败，需要手动重新启动实例。

CPU 使用率通常徘徊在 15% 左右，当我们进行深夜处理时，该值会达到峰值。

来自mysql innodb_buffer_pool_size 应该有多大？

SELECT CEILING(Total_InnoDB_Bytes*1.6/POWER(1024,3)) RIBPS FROM
(SELECT SUM(data_length+index_length) Total_InnoDB_Bytes
FROM information_schema.tables WHERE engine='InnoDB') A;

根据需要提供 10GB 来保存内存中的所有数据和索引。

SELECT (PagesData*PageSize)/POWER(1024,3) DataGB FROM
(SELECT variable_value PagesData
FROM information_schema.global_status
WHERE variable_name='Innodb_buffer_pool_pages_data') A,
(SELECT variable_value PageSize
FROM information_schema.global_status
WHERE variable_name='Innodb_page_size') B;

InnoDB 缓冲池中提供 4.6GB

SHOW FULL PROCESSLIST

仅显示几个进程，没有挂起的线程。

我的问题是，有没有一种方法可以确保可释放内存永远不会超过某个点并被释放回来以供使用，例如它永远不会低于 2GB，因此如果内存占用很大，它不会耗尽内存。

我知道这可能会影响性能，但在我扩展到更大的实例（成本加倍）并经历同样​​缓慢下降到 0 之前，我想看看它的性能如何，因为它比生产更好机器随机崩溃。

附加信息：

我已将各种 MySQL 输出添加到https://pastebin.com/CkRxqL04

不太确定如何在 RDS 实例上运行 Unix …

我们正在运行一个 Aurora PostgreSQL 集群，其中包含一个只读副本和主节点。

定期出现非常重的写入负载，导致较高的复制延迟。这可能会导致只读副本重新启动，这对于高可用性环境中的我们来说是不希望的。发生这种情况时，通过只读端点连接到集群的客户端会收到此 JDBC 错误：org.postgresql.util.PSQLException: FATAL: the database system is starting up。此外，AWS 控制台在日志中显示了这些内容：

只读副本已经落后于主数据库太多了。重新启动 postgres。

其次是

数据库实例已重新启动

我们可以容忍只读副本落后几分钟，但不能容忍只读副本重新启动才能赶上。

有没有办法防止只读副本在这些时间段内重新启动？

或者，是否有任何建议的调整可以减少写入负载较重期间的复制延迟？

将应用程序及其数据库从经典 PostgreSQL 数据库迁移到 Amazon Aurora RDS PostgreSQL 数据库（均使用 9.6 版本）后，我们发现特定查询在 Aurora 上的运行速度要慢得多——大约慢 10 倍在 PostgreSQL 上。

两个数据库都具有相同的配置，无论是硬件还是 pg_conf。

查询本身相当简单。它是从我们用 Java 编写的后端生成的，并使用 jOOQ 编写查询：

with "all_acp_ids"("acp_id") as (
    select acp_id from temp_table_de3398bacb6c4e8ca8b37be227eac089
) 
select distinct "public"."f1_folio_milestones"."acp_id", 
    coalesce("public"."sa_milestone_overrides"."team", 
    "public"."f1_folio_milestones"."team_responsible") 
from "public"."f1_folio_milestones" 
left outer join 
    "public"."sa_milestone_overrides" on (
        "public"."f1_folio_milestones"."milestone" = "public"."sa_milestone_overrides"."milestone" 
        and "public"."f1_folio_milestones"."view" = "public"."sa_milestone_overrides"."view" 
        and "public"."f1_folio_milestones"."acp_id" = "public"."sa_milestone_overrides"."acp_id"
)
where "public"."f1_folio_milestones"."acp_id" in (
    select "all_acp_ids"."acp_id" from "all_acp_ids"
)

用temp_table_de3398bacb6c4e8ca8b37be227eac089是单个列的表，f1_folio_milestones（17万个条目）和sa_milestone_overrides（100万左右的条目）是具有在所有用于列索引类似设计的表LEFT OUTER JOIN。

temp_table_de3398bacb6c4e8ca8b37be227eac089 最多可以包含 5000 …

我正在使用AWS Aurora PostgreSQL Serverless自动缩放。看起来好像缩放清除了共享缓冲区，所以当我们想要提高性能时，我们被迫面对 I/O 瓶颈。在我们热身之后，我们看到了巨大的性能提升。但是，如果我们在缩放后背靠背运行，则第二次运行会更快。虽然我没有看到任何关于共享缓冲区是否在缩放时被清除的具体信息，但我几乎肯定它是。

Aurora Serverless 目前正在使用PostgreSQL 10.14，并且支持pg_prewarm扩展。它看起来像最新的文件显示在服务器重新启动后prewarm支持自动prewarm，但这是无服务器并不会出现提自动预暖的一个版本的文档中。

我发现这篇文章在重新启动服务器或从崩溃中恢复时非常适合 PostgreSQL。

1. 如果我们至少可以在缩放后保留下 ACU 节点的共享缓冲区的内容，那就没问题了。
2. 如果我们可以提前预热需要在内存中的内容，那就太棒了！
3. 有些桌子非常大，我们希望有选择地预热我们想要的作品。 pg_prewarm支持first_block和last_block阻止表/索引的编号，但是如何知道要放入哪些值呢？

我们提前知道我们的峰值是什么时候，并告诉 RDS 在此之前进行扩展，因此我们有一个可以准备的时间窗口。

我有哪些选择？

我有一个包含约 20 亿行数据的表，我想创建另一个包含一些聚合的表。看起来 PostgreSQL 使用临时磁盘空间来执行这些查询。我可以创建表...

CREATE TABLE my_new_table ...

但是当我插入数据时：

INSERT INTO my_new_table SELECT
   col_1,
   col_2,
   col_3,
   col_4,
   col_5,
   col_6,
   col_7,
   col_8,
   col_9,
   sum(col_10),
   sum(col_11)
FROM
   my_table
GROUP BY
   1,2,3,4,5,6,7,8,9

PostgreSQL 似乎使用临时文件来存储结果，并且空间不足，例如出现如下错误：

无法写入文件“base/pgsql_tmp/pgsql_tmp31757.25”：设备上没有剩余空间

从 EXPLAIN 的结果来看，我怀疑这是来自某种排序。有办法避免这种情况吗？不会有那么多的输出行，所以不知何故，我觉得好像应该有一种方法可以在输出处做得更到位......但这是一个非常模糊的直觉。

我有下表：

CREATE TABLE `tokens` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `s_id` int(10) unsigned NOT NULL,
  `a_token` char(40) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,
  `a_token_exp` int(10) unsigned NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `u_a_token` (`a_token`) USING HASH,
  KEY `f_seid` (`s_id`),
  CONSTRAINT `f_seid` FOREIGN KEY (`s_id`) REFERENCES `sessions` (`id`) ON DELETE CASCADE ON UPDATE NO ACTION
) ENGINE=InnoDB AUTO_INCREMENT=34 DEFAULT CHARSET=latin1

我想更改字符集，a_token因为我们使用以下命令仅使用 ascii 字符：

ALTER TABLE tokens MODIFY a_token CHAR(40) CHARACTER SET ascii COLLATE ascii_general_ci NOT NULL; …