我有一个 lambda 函数，它从消息队列接收新注册用户的数据，并将相同的数据插入到两个不同的数据库中。
这两个数据库属于两个不同的微服务。第一个 - 使用 RDS postgres 的用户服务，第二个 - 管理服务，其数据库基本上是单个 DynamoDB 表。
我希望在两个数据库中实现数据插入的“全有或全无”行为 - 要么在两个数据库中插入成功，要么在其中任何一个数据库中都没有发生插入。
我可以在代码级别实现这种功能，但是如果假设我在 5 个而不是 2 个不同的数据库中进行了“全部或全部”插入，那么代码会非常混乱。
我想知道在与不同的数据库交互时是否有某种标准方法可以实现类似原子事务的行为。
我有一个 RDS Postgresql 12 实例，它分配了 11,000,000 MB 的 io1 磁盘空间，还有 7,300,000 MB 的可用存储空间。
这意味着数据库只使用了 11TB - 7.3TB = 3.7TB 的磁盘空间，对吗？还是我错过了什么？
因此，我启动了一个分配 5TB 磁盘空间的新实例，执行了 pg_dump 和 pg_restore。
在 pg_restore 期间，可用存储空间线性下降到零，然后在 AWS 自动添加 2.5TB 时飙升。
这是怎么回事？为什么新实例使用更多磁盘空间？
奇怪的是，可用空间慢慢增加了，尽管自从恢复完成后我还没有碰过系统。
在 RDS 中运行的 Postgres 只能通过 EKS 集群访问……因此我的集群中有一个（通用）pod，它允许我访问我们的 postgres 实例。我需要更改我当前正在使用/以（root 用户）身份登录的角色的密码。问题是，当我尝试提醒用户或角色时，postgres 说用户/角色不存在，即使我可以清楚地看到它并且我以用户身份登录！我以 root（操作系统级别）身份登录到 postgres，并且我是 postgres root 用户（不是 postgres，而是我将ABcDeFGh在这个问题中调用的超级用户）
postgres=> select user;
user
----------
ABcDeFGh
(1 row)
postgres=> select rolname, rolsuper from pg_roles;
rolname | rolsuper
---------------------------+----------
pg_monitor | f
pg_read_all_settings | f
pg_read_all_stats | f
pg_stat_scan_tables | f
pg_read_server_files | f
pg_write_server_files | f
pg_execute_server_program | f
pg_signal_backend | f
rds_superuser | f
rds_replication | f
rds_iam | f
rds_password | f
rds_ad | f
rdsadmin | t
ABcDeFGh | f
rdsrepladmin | f
rdstopmgr | f
(20 rows)
我登录的用户是 ABcDeFGh。甚至是特定的查询（顺便说一句，我不是 postgres 人）
postgres=> \dg ABcDeFGh
List of roles
Role name | Attributes | Member of
-----------+------------+-----------
postgres=> \dg abcdefgh
List of roles
Role name | Attributes | Member of
-----------+------------+-----------
postgres=> \du abcdefgh
List of roles
Role name | Attributes | Member of
-----------+------------+-----------
postgres=> \du ABcDeFGh
List of roles
Role name | Attributes | Member of
-----------+------------+-----------
但是这个（列表被截断）：
postgres=> \du
List of roles
Role name | Attributes | Member of
---------------------+------------------------------------------------------------+-------------------------------------------------------------
ABcDeFGh | Create role, Create DB +| {rds_superuser}
| Password valid until infinity |
这个（列表被截断）：
postgres=> \dg
List of roles
Role name | Attributes | Member of
---------------------+------------------------------------------------------------+-------------------------------------------------------------
ABcDeFGh | Create role, Create DB +| {rds_superuser}
| Password valid until infinity |
（现在我刚刚注意到\du并且\dg是同一件事或似乎是彼此的别名）
所以这是非常令人困惑和沮丧的。alter如您所见，我对 and 使用了全小写和区分大小写的名称\dg。尝试更改密码时出现的错误是role或者user不存在。它显然似乎存在。
alter role 'ABcDeFGh' with password '<REDACTED>' valid until '2023-01-02T00:13:34+00:00';
ERROR: syntax error at or near "'ABcDeFGh'"
我能找到的所有文档都无法解释这里可能发生的事情。用户显然存在，因为我以用户身份登录。我真的很讨厌把时间浪费在这种来自软件的模棱两可的垃圾上。
我在 S3 中有一个启用了本地 TDE 的 SQL DB 备份文件以及 Cert 和 Pvt 密钥文件。如何使用在源数据库备份期间提供的相同主密钥密码在 AWS RDS SQL 数据库中恢复？
当我尝试在 RDS 中运行以下查询时，出现“用户无权执行此操作”的错误
`CREATE MASTER KEY ENCRYPTION
BY PASSWORD='Strong11111@Password'`
aws 网站提供以下 SP 用于恢复启用 TDE 的 SQL DB
`EXECUTE msdb.dbo.rds_restore_tde_certificate
@certificate_name='UserTDECertificate_certificate_name'
, @certificate_file_s3_arn='arn:aws:s3:::bucket_name/certificate_file_name.cer'
, @private_key_file_s3_arn='arn:aws:s3:::bucket_name/key_file_name.pvk'
, @kms_password_key_arn='arn:aws:kms:region:account-id:key/key-id'`
@kms_password_key_arn – 用于加密私钥密码的对称 KMS 密钥的 ARN。
只是想知道当我们无法在 RDS 中运行/创建主密钥加密查询时，我们将在哪里/如何使用在创建 .bak 文件期间使用的相同密码 ('Strong11111@Password')获取参数@kms_password_key_arn的值。
任何建议，将不胜感激。提前致谢！
我在 AWS RDS 上运行 postgres。RDS 会自行创建一些用户，例如rdsadmin和rdsrepladmin。我熟悉这些
rdstopmgr但是，当我查询 postgres 的角色时，我也看到了。谷歌对这个用户没有太多要说的，AWS RDS docs也没有。但是，我认为这也可能是 RDS 用户。
原因如下：当我在 Google 上搜索“RDS 顶部”时，我从 AWS RDS 文档中找到了这个页面。这让我觉得rdstopmgr可能是用于性能洞察的 RDS 控制用户。
我已向 AWS 提交了反馈，要求他们更新其文档以包含此内容。但是，我也想在这里向社区提出这个问题。你同意我的结论，还是你不知道这个用户？
我们的团队正在将我们的一个数据库迁移到 Amazon RDS MS SQL Server。作为其中的一部分，我们必须重写一些存储过程。
我们有一个将数据库备份到网络存储的存储过程。
BACKUP DATABASE [MyDB] TO DISK = '\\myserver\share\MydbBackup.bak'
WITH RETAINDAYS = 0,
INIT
上面的存储过程是阻塞的，即它会暂停执行行exec stored_proc——直到备份完成。
我已经更改了该存储过程，以便它使用存储过程，rds_backup_database以便将备份保存在 S3 存储桶中。
exec msdb.dbo.rds_backup_database
@source_db_name='MyDB',
@s3_arn_to_backup_to='arn:aws:s3:::temp-poc-bucket/db_backups/MyDBBackup.bak',
@overwrite_s3_backup_file=1;
问题是我们的工作流程（从我们的应用程序调用存储过程）要求它是同步的。
有没有办法“等待”msdb.dbo.rds_backup_database存储过程的执行？
AWS RDS文档。
我从 Web 界面看到需要对我的 RDS postgresql 实例进行维护，所以我运行了aws rds describe-pending-maintenance-actions，它说有一个“系统更新”，因为“有新的操作系统更新可用”。
没关系，所以我在 90 分钟前（aws rds stop-db-instance当时aws rds start-db-instance）重新启动了实例。
90 多分钟后，实例仍然“需要维护”。
我做错了什么，或者没有做什么？或者这只是一个通知，表明 AWS 将做一些我无法控制的事情？
$ aws rds describe-pending-maintenance-actions --output=table
-------------------------------------------------------------------------------------------
| DescribePendingMaintenanceActions |
|| PendingMaintenanceActions ||
|+---------------------+-----------------------------------------------------------------+|
|| ResourceIdentifier | arn:aws:rds:us-east-1:123456789012:db:xxxxxxxxxxxx ||
|+---------------------+-----------------------------------------------------------------+|
||| PendingMaintenanceActionDetails |||
||+-----------------------------+-------------------------------------------------------+||
||| Action | system-update |||
||| AutoAppliedAfterDate | 2022-06-30T00:00:00+00:00 |||
||| CurrentApplyDate | 2022-06-30T00:00:00+00:00 |||
||| Description | New Operating System update is available |||
||| ForcedApplyDate | 2022-10-30T00:00:00+00:00 |||
||+-----------------------------+-------------------------------------------------------+||
|| PendingMaintenanceActions ||
|+---------------------+-----------------------------------------------------------------+|
|| ResourceIdentifier | arn:aws:rds:us-east-1:123456789012:yyyyyyyyyyyyy ||
|+---------------------+-----------------------------------------------------------------+|
||| PendingMaintenanceActionDetails |||
||+-----------------------------+-------------------------------------------------------+||
||| Action | system-update |||
||| AutoAppliedAfterDate | 2022-06-30T00:00:00+00:00 |||
||| CurrentApplyDate | 2022-06-30T00:00:00+00:00 |||
||| Description | New Operating System update is available |||
||| ForcedApplyDate | 2022-10-30T00:00:00+00:00 |||
||+-----------------------------+-------------------------------------------------------+||
自从我从 MySQL 5.6 更新到 5.7 后，我的 Aurora RDS 实例中的查询开始变得非常缓慢。在我本地的 XAMPP 中，相同的查询需要几秒钟，但在 RDS 中，其中一些查询大约需要 6 分钟。为了为我的客户提供一个快速的解决方案，我将数据库从 Aurora RDS 迁移到了一个普通的 MariaDB RDS 实例（可能有点矫枉过正，但我需要快速做一些事情）。迁移后查询时间和本地环境差不多，可以接受，但是迁移到现在已经三周了，查询又很慢，大概6分钟左右。CPU 上升到几乎 50%，并且 DB 中只有一个连接，一个执行慢速查询的连接。我检查并修改了 RDS 中的参数，特别是优化器开关，但它们对查询速度没有明显影响。我还优化了没有改进的表。我正在考虑一个日志表或类似的表，它可能会在三周后增长太多，因此会减慢我的查询速度，但这只是一个想法。在这一点上，我有点失落。这些慢查询中的表在 63 到 200K+ 行之间。
最慢的查询是这样的：
SELECT *
FROM bicycles AS Bicycle
LEFT JOIN loans AS Loan ON Loan.uuid = (
SELECT
loans.uuid
FROM loans
WHERE loans.bicycle_uuid = Bicycle.uuid
ORDER BY loans.date_created DESC
LIMIT 1
)
WHERE Bicycle.status = 'SCRAPPED'
AND Bicycle.number <= 9900
ORDER BY Loan.date_created DESC, Bicycle.number DESC
961 rows in set (6 min 23.28 sec)
这是查询的解释：
+----+--------------------+---------+------------+--------+---------------+--------------+---------+------+------+----------+----------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+--------------------+---------+------------+--------+---------------+--------------+---------+------+------+----------+----------------------------------------------+
| 1 | PRIMARY | Bicycle | NULL | ALL | number | NULL | NULL | NULL | 2082 | 9.99 | Using where; Using temporary; Using filesort |
| 1 | PRIMARY | Loan | NULL | eq_ref | PRIMARY | PRIMARY | 16 | func | 1 | 100.00 | Using where |
| 2 | DEPENDENT SUBQUERY | loans | NULL | index | bicycle_uuid | date_created | 5 | NULL | 428 | 10.00 | Using where |
+----+--------------------+---------+------------+--------+---------------+--------------+---------+------+------+----------+----------------------------------------------+
3 rows in set, 2 warnings (0.00 sec)
桌上自行车的索引：
+----------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+----------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| bicycles | 0 | PRIMARY | 1 | uuid | A | 2082 | NULL | NULL | | BTREE | | |
| bicycles | 0 | number | 1 | number | A | 2082 | NULL | NULL | | BTREE | | |
+----------+------------+----------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
2 rows in set (0.00 sec)
表贷款指数：
+-------+------------+---------------------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-------+------------+---------------------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| loans | 0 | PRIMARY | 1 | uuid | A | 219864 | NULL | NULL | | BTREE | | |
| loans | 1 | anchor_uuid | 1 | anchor_uuid | A | 1047 | NULL | NULL | | BTREE | | |
| loans | 1 | use_uuid | 1 | use_uuid | A | 4076 | NULL | NULL | YES | BTREE | | |
| loans | 1 | date_created | 1 | date_created | A | 213634 | NULL | NULL | | BTREE | | |
| loans | 1 | bicycle_uuid | 1 | bicycle_uuid | A | 428 | NULL | NULL | | BTREE | | |
| loans | 1 | date_created_bicycle_uuid | 1 | date_created | A | 212288 | NULL | NULL | | BTREE | | |
| loans | 1 | date_created_bicycle_uuid | 2 | bicycle_uuid | A | 218719 | NULL | NULL | | BTREE | | |
+-------+------------+---------------------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
7 rows in set (0.00 sec)
我正在使用 db.r3.large 实例、2vCPU、15.25 GiB RAM，未经过 EBS 优化。MySQL 版本是 5.7.34，带有 MariaDB。存储是 IOPS 预置 SSD (io1)，100GiB 分配存储，5000 预置 IOPS。
根据用户请求，我添加下一个表格信息：
+----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| bicycles | CREATE TABLE `bicycles` (
`uuid` binary(16) NOT NULL,
`number` int(14) NOT NULL,
`date_created` datetime NOT NULL,
`status` varchar(20) COLLATE utf8_spanish_ci NOT NULL DEFAULT 'CIRCULATION',
`is_electric` tinyint(1) NOT NULL DEFAULT 0,
PRIMARY KEY (`uuid`),
UNIQUE KEY `number` (`number`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci |
+----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.000 sec)
+----------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+------------+-----------------+----------+----------------+---------+------------------+-----------+
| Name | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time | Update_time | Check_time | Collation | Checksum | Create_options | Comment | Max_index_length | Temporary |
+----------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+------------+-----------------+----------+----------------+---------+------------------+-----------+
| bicycles | InnoDB | 10 | Dynamic | 2082 | 78 | 163840 | 0 | 81920 | 0 | NULL | 2022-01-28 12:13:25 | 2022-01-28 12:13:25 | NULL | utf8_spanish_ci | NULL | | | 0 | N |
+----------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+------------+-----------------+----------+----------------+---------+------------------+-----------+
1 row in set (0.001 sec)
+-------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Table | Create Table |
+-------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| loans | CREATE TABLE `loans` (
`uuid` binary(16) NOT NULL,
`use_uuid` binary(16) DEFAULT NULL,
`bicycle_uuid` binary(16) NOT NULL,
`anchor_uuid` binary(16) NOT NULL,
`date_created` datetime NOT NULL,
`type_access` enum('UNKNOWN','CARD','APP','SYSTEM','WORKER') COLLATE utf8_spanish_ci NOT NULL,
PRIMARY KEY (`uuid`),
KEY `anchor_uuid` (`anchor_uuid`),
KEY `use_uuid` (`use_uuid`),
KEY `date_created` (`date_created`),
KEY `bicycle_uuid` (`bicycle_uuid`),
KEY `date_created_bicycle_uuid` (`date_created`,`bicycle_uuid`),
CONSTRAINT `fk_loans_anchors` FOREIGN KEY (`anchor_uuid`) REFERENCES `anchors` (`uuid`) ON DELETE NO ACTION ON UPDATE NO ACTION,
CONSTRAINT `fk_loans_bicycles` FOREIGN KEY (`bicycle_uuid`) REFERENCES `bicycles` (`uuid`) ON DELETE NO ACTION ON UPDATE NO ACTION,
CONSTRAINT `fk_loans_users` FOREIGN KEY (`use_uuid`) REFERENCES `users` (`uuid`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci |
+-------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.000 sec)
+-------+--------+---------+------------+--------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+------------+-----------------+----------+----------------+---------+------------------+-----------+
| Name | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time | Update_time | Check_time | Collation | Checksum | Create_options | Comment | Max_index_length | Temporary |
+-------+--------+---------+------------+--------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+------------+-----------------+----------+----------------+---------+------------------+-----------+
| loans | InnoDB | 10 | Dynamic | 216920 | 99 | 21561344 | 0 | 75284480 | 7340032 | NULL | 2022-01-28 12:37:06 | 2022-01-28 12:37:22 | NULL | utf8_spanish_ci | NULL | | | 0 | N |
+-------+--------+---------+------------+--------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+------------+-----------------+----------+----------------+---------+------------------+-----------+
1 row in set (0.001 sec)
这是添加建议索引后句子的解释：
+----+--------------------+------------+------------+--------+-----------------------------------+----------------------------+---------+-------------------------------+------+----------+-----------------------------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+--------------------+------------+------------+--------+-----------------------------------+----------------------------+---------+-------------------------------+------+----------+-----------------------------------------------------------+
| 1 | PRIMARY | Bicycle | NULL | range | number,bicycles_ndx_status_number | bicycles_ndx_status_number | 66 | NULL | 961 | 100.00 | Using where; Using index; Using temporary; Using filesort |
| 1 | PRIMARY | Loan | NULL | eq_ref | PRIMARY | PRIMARY | 16 | func | 1 | 100.00 | Using where |
| 1 | PRIMARY | LoanAnchor | NULL | eq_ref | PRIMARY | PRIMARY | 16 | bicicas.Loan.anchor_uuid | 1 | 100.00 | NULL |
| 1 | PRIMARY | LoanBench | NULL | eq_ref | PRIMARY | PRIMARY | 16 | bicicas.LoanAnchor.bench_uuid | 1 | 100.00 | NULL |
| 1 | PRIMARY | User | NULL | eq_ref | PRIMARY | PRIMARY | 16 | func | 1 | 100.00 | Using where |
| 3 | DEPENDENT SUBQUERY | users | NULL | ref | uuid | uuid | 16 | bicicas.Loan.use_uuid | 2 | 100.00 | Using index condition; Using filesort |
| 2 | DEPENDENT SUBQUERY | loans | NULL | ref | bicycle_uuid | bicycle_uuid | 16 | bicicas.Bicycle.uuid | 452 | 100.00 | Using index condition; Using filesort |
+----+--------------------+------------+------------+--------+-----------------------------------+----------------------------+---------+-------------------------------+------+----------+-----------------------------------------------------------+
7 rows in set, 3 warnings (0.00 sec)
从在 Amazon RDS Postgres 实例上运行的 plpgsql 脚本中，是否可以获取有关实例配置的信息？如何检索实例的数据库实例 ID、ARN（Amazon 资源名称）或终端节点？
我想将它用作一些 plpgsql-script 中的检查，以 100% 确保它不会在生产数据库上执行它的操作。
我们正在考虑将 Oracle RDS 数据库迁移到 Athena Trino Datalake。
我们将保持所有数据库名称、模式、表和列相同。
针对 Oracle RDS 数据库正确运行的 SQL 是否可以 100% 保证针对 Athena Trina Datalake 正确运行（可能存在细微差异，例如没有 ORDER BY 的查询的排序顺序）？
我的猜测是它不会，尽管希望大多数这样的 SQL 都能在两个系统中正确运行。