​​RDS PostgreSQL 16 on AWS: 🎉

https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-versions.html#postgresql-versions-version161

#RDS #PosrgreSQL

🆕 RDS for Db2 🎉

https://aws.amazon.com/blogs/aws/getting-started-with-new-amazon-rds-for-db2/

#RDS #IBM #Db2

⚠️ Starting June 1, 2024, Amazon RDS began automatically upgrading instances:

db.m4 => db.m5
db.r4 => db.r5
db.t2 => db.t3

Amazon RDS ends support for db.m4/r4/t2 — December 31, 2024.

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html

#RDS

​​🆕 RDS with DLV (Dedicated Log Volumes) for PostgreSQL, MySQL, and MariaDB:

https://aws.amazon.com/blogs/database/enhance-database-performance-with-amazon-rds-dedicated-log-volumes/

RDS with DLV use cases:

• Large allocated storage (over 5 TiB)
• High IOPS requirements
• Transaction-intensive workloads
• Latency-sensitive workloads
• Using io1 or io2 Provisioned IOPS storage

⚠️ Enabling DLV requires database downtime, but this can be reduced by enabling DLV on a new or existing read replica and then promoting it as the primary.

#RDS

#AWS #RDS

#aws #rds
Короткий материал на уровне senior+

Нырни на самое дно. Без страховки.

Иногда, когда проект достиг своего максимума на данный момент, приходится оптимизировать уже не софт и не пайплайны, а саму инфраструктуру.
Например параметры движка или базу.
Так и вышло в этот раз.

Традиционные параметры типа CPU/memory usage, connections, memory usage, latency, IOPS, lags, cache, CRUD throughput, slow logs и прочее мы научились мониторить и алёртить, что заставило нас оптимизировать запросы к бд и серьёзно снизило нагрузку.

Совсем недавно мы нырнули глубже и поменяли пару параметров в ущерб потери 1 секунды данных в случае аутейджа со стороны Амазон.
Данный проект не использует критически важные операции для транзакций типа финансовых операций, так что мы имеем право это включить. Если у вас финансовые операции или любые критичные операции вам НЕЛЬЗЯ это включать. Нельзя и запомните это.

innodb_flush_log_at_trx_commit
Значение 2 означает, что журнал транзакций (redo log) записывается в буфер операционной системы при каждой фиксации (commit), но сброс на диск происходит только раз в секунду
- Улучшает производительность, так как уменьшает операции ввода-вывода диска
- Снижает надежность: возможна потеря транзакций последней секунды при сбое сервера/ОС
- Компромисс между производительностью (выше) и надежностью (ниже) по сравнению со значением 1

innodb_trx_commit_allow_data_loss
Значение 1 означает, что система разрешает возможную потерю данных для увеличения производительности
- Значительно ускоряет операции фиксации транзакций
- Снижает гарантии сохранности данных
- Может привести к потере транзакций при сбоях

Результат дал о себе знать почти сразу, но нам явно придётся ещё несколько раз нырять для более точного тюнинга. Будем наблюдать и изменять под себя.

DevOps это не всегда общение, ямлоделие, пайплайны и кубер.
Иногда это тюнинг БД, когда все остальные элементы уже исчерпаны или нет на это бюджета(выше тип инстанса, gravitron v4, больше read реплик, RDS proxy, queries tuning etc).

Ну и код для примера:

resource "aws_rds_cluster_parameter_group" "this" {
...
  parameter {
    apply_method = "immediate"
    name         = "innodb_flush_log_at_trx_commit"
    value        = "2"
  }
  parameter {
    apply_method = "immediate"
    name         = "innodb_trx_commit_allow_data_loss"
    value        = "1"
  }
}

Миграция 4 миллионов баз на 3000 RDS в 13 регионах на Aurora:

https://www.atlassian.com/blog/atlassian-engineering/migrating-jira-database-platform-to-aws-aurora

#RDS #Aurora

Теперь можно копировать RDS снэпшоты в другой регион другого аккаунта сразу.

https://aws.amazon.com/about-aws/whats-new/2025/09/amazon-rds-cross-region-cross-account-snapshot-copy/

Раньше приходилось копировать сначала в другой аккаунт, после уже в другой регион.

Кто настраивал AWS Backup на такие Disaster Recovery сценарии, стоит проверить ваши джобы для RDS.

4 года они тупо фейлились (при cross-region&cross-account), а теперь честно будут отрабатывать и тратить ваши деньги. 😁

#RDS #Backup

PostgreSQL 18 on AWS 🎉

https://aws.amazon.com/about-aws/whats-new/2025/09/postgresql-180-amazon-rds-database-preview-environment/

https://www.postgresql.org/about/news/postgresql-18-released-3142/

- AIO (Asynchronous I/O
- virtual/generated columns
- OAuth2/SSO support

⚠️ page checksums enabled by default (use --no-data-checksums option when using pg_upgrade).

#RDS #PostgreSQL

🎈 RDS Extended Support или обладателям RDS PostgreSQL 11 и PostgreSQL 12 в 2025-м году посвящается.

Вдруг вы заходите раз в год в старые проекты. Радуетесь, что у вас не EKS и делать там особо нечего — работает себе и работает.

Однако стоит обратить на колонку стоимости за базу данных. За этот год счастливые обладатели PostgreSQL 12 обнаружат, что вместо привычных 50$/мес. за смешную db.t3.medium набегает как за "взрослую" — 200$/мес.

Ещё более счастливые обладатели PostgreSQL 11 (не) заметили это ещё в прошлом году. А вам только сейчас (не) повезло.

https://aws.amazon.com/rds/postgresql/pricing/

RDS Extended Support начал действовать в 2024-м году и его действие аналогично тому, как это действует для EKS — старые версии PostgreSQL и MySQL будут дополнительно взимать существенную дополнительную плату.

В результате получается в разы больше обычного счета за поддержку старых версий баз данных.

Пока это касается лишь только PostgreSQL и MySQL баз данных.

Кому приготовиться?

Обладателям PostgreSQL 13 осталось мучаться полгода и их ожидает такое же счастье.

https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-release-calendar.html

Не менее счастливые обладатели MySQL 5.7 тоже уже второй год зарабатывают на значок почётного спонсора AWS, а в следующем году к ним присоединятся и обладатели MySQL 8.0. Дополнительный повод переехать на MariaDB, у которой нет таких проблем (RDS Extended Support к ней не применяется).

#RDS #cost_optimization