Появился экспорт #RDS снэпшотов на S3:
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ExportSnapshot.html
Аналогично для #Aurora:
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_ExportSnapshot.html
Можно экспортировать не весь снэпшот, а лишь часть, сохраняется в parquet-формате.
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ExportSnapshot.html
Аналогично для #Aurora:
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_ExportSnapshot.html
Можно экспортировать не весь снэпшот, а лишь часть, сохраняется в parquet-формате.
Aurora PostgreSQL глобализировалась:
https://aws.amazon.com/about-aws/whats-new/2020/03/amazon-aurora-with-postgresql-compatibility-supports-amazon-aurora-global-database/
На текущий момент поддерживается лишь версия Aurora PostgreSQL 10.11, которую нужно создать или восстановить из снэпшота версии PostgreSQL 10.7 на инстансх
#Aurora
https://aws.amazon.com/about-aws/whats-new/2020/03/amazon-aurora-with-postgresql-compatibility-supports-amazon-aurora-global-database/
На текущий момент поддерживается лишь версия Aurora PostgreSQL 10.11, которую нужно создать или восстановить из снэпшота версии PostgreSQL 10.7 на инстансх
db.r4 или db.r5 типа, а после создания добавить регионы (до четырёх штук - на картинке), получив таким образом глобальную работу.#Aurora
Aurora Serverless V2:
https://aws.amazon.com/about-aws/whats-new/2020/12/introducing-the-next-version-of-amazon-aurora-serverless-in-preview/
Новая серверлесная Аврора масштабируется мгновенно (за доли секунды).
#Aurora #Serverless
https://aws.amazon.com/about-aws/whats-new/2020/12/introducing-the-next-version-of-amazon-aurora-serverless-in-preview/
Новая серверлесная Аврора масштабируется мгновенно (за доли секунды).
#Aurora #Serverless
Экспорт RDS Aurora Serverless снэпшотов на S3:
https://github.com/devetry/aurora-serverless-to-s3
Официально нет возможности экспортировать снэпшоты на S3 для Aurora Serverless. Если это требуется, то поможет данная утилита, которая делает экспорт путём создания из снэпшота "несерверлесной" Авроры, снятия снэпшота и после экспорта её удаления.
#Aurora
https://github.com/devetry/aurora-serverless-to-s3
Официально нет возможности экспортировать снэпшоты на S3 для Aurora Serverless. Если это требуется, то поможет данная утилита, которая делает экспорт путём создания из снэпшота "несерверлесной" Авроры, снятия снэпшота и после экспорта её удаления.
#Aurora
GitHub
GitHub - devetry/aurora-serverless-to-s3
Contribute to devetry/aurora-serverless-to-s3 development by creating an account on GitHub.
Aurora Serverless v2:
https://aws.amazon.com/blogs/aws/amazon-aurora-serverless-v2-is-generally-available-instant-scaling-for-demanding-workloads/
Aurora Serverless v2 enables you to scale your database to hundreds of thousands of transactions per second and cost-effectively manage the most demanding workloads. It scales database capacity in fine-grained increments to closely match the needs of your workload without disrupting connections or transactions.
If you have an existing Aurora cluster, you can create an Aurora Serverless v2 instance within the same cluster. This way, you’ll have a mixed configuration cluster where both provisioned and Aurora Serverless v2 instances can coexist within the same cluster.
Aurora Serverless v2 capacity scales up and down within the minimum
Versions supported:
🔹 PostgreSQL 13
🔸 MySQL 8.0
#Aurora #Serverless
https://aws.amazon.com/blogs/aws/amazon-aurora-serverless-v2-is-generally-available-instant-scaling-for-demanding-workloads/
Aurora Serverless v2 enables you to scale your database to hundreds of thousands of transactions per second and cost-effectively manage the most demanding workloads. It scales database capacity in fine-grained increments to closely match the needs of your workload without disrupting connections or transactions.
If you have an existing Aurora cluster, you can create an Aurora Serverless v2 instance within the same cluster. This way, you’ll have a mixed configuration cluster where both provisioned and Aurora Serverless v2 instances can coexist within the same cluster.
Aurora Serverless v2 capacity scales up and down within the minimum
0.5 ACUs and maximum 128 ACUs configuration. Versions supported:
🔹 PostgreSQL 13
🔸 MySQL 8.0
#Aurora #Serverless
👍4🎉1
RDS Blue/Green Deployments:
https://aws.amazon.com/blogs/aws/new-fully-managed-blue-green-deployments-in-amazon-aurora-and-amazon-rds/
■ You can use Blue/Green Deployments to create a separate, synchronized, fully managed staging environment that mirrors the production environment. The staging environment clones your production environment’s primary database and in-Region read replicas. Blue/Green Deployments keep these two environments in sync using logical replication.
■ In as fast as a minute, you can promote the staging environment to be the new production environment with no data loss. During switchover, Blue/Green Deployments blocks writes on blue and green environments so that the green catches up with the blue, ensuring no data loss. Then, Blue/Green Deployments redirects production traffic to the newly promoted staging environment, all without any code changes to your application.
■ With Blue/Green Deployments, you can make changes, such as major and minor version upgrades, schema modifications, and operating system or maintenance updates, to the staging environment without impacting the production workload.
RDS Blue/Green Deployments is available on:
🔹 RDS/Aurora MySQL 5.6+
🔸 RDS/Aurora MariaDB 10.2+
#RDS #Aurora
https://aws.amazon.com/blogs/aws/new-fully-managed-blue-green-deployments-in-amazon-aurora-and-amazon-rds/
■ You can use Blue/Green Deployments to create a separate, synchronized, fully managed staging environment that mirrors the production environment. The staging environment clones your production environment’s primary database and in-Region read replicas. Blue/Green Deployments keep these two environments in sync using logical replication.
■ In as fast as a minute, you can promote the staging environment to be the new production environment with no data loss. During switchover, Blue/Green Deployments blocks writes on blue and green environments so that the green catches up with the blue, ensuring no data loss. Then, Blue/Green Deployments redirects production traffic to the newly promoted staging environment, all without any code changes to your application.
■ With Blue/Green Deployments, you can make changes, such as major and minor version upgrades, schema modifications, and operating system or maintenance updates, to the staging environment without impacting the production workload.
RDS Blue/Green Deployments is available on:
🔹 RDS/Aurora MySQL 5.6+
🔸 RDS/Aurora MariaDB 10.2+
#RDS #Aurora
🔥11
🆕 Aurora PostgreSQL + Local write forwarding
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-postgresql-write-forwarding.html
With write forwarding, your applications can simply send both read and write requests to a read replica, and Aurora will take care of forwarding the write requests to the writer instance in your cluster.
#Aurora #PostgreSQL
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-postgresql-write-forwarding.html
With write forwarding, your applications can simply send both read and write requests to a read replica, and Aurora will take care of forwarding the write requests to the writer instance in your cluster.
#Aurora #PostgreSQL
🔥19👍7👎2
🆕 Aurora + Global Database writer endpoint
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-connecting.html#global-endpoints
Before: When switching Aurora database operations between regions, developers had to manually update application connection strings to point to the new primary database location, which required code changes and potential downtime.
Now: Global Database writer endpoint automatically tracks and connects to the active writer instance across regions, eliminating the need for manual connection updates and making regional failovers completely transparent to applications.
#Aurora
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-connecting.html#global-endpoints
Before: When switching Aurora database operations between regions, developers had to manually update application connection strings to point to the new primary database location, which required code changes and potential downtime.
Now: Global Database writer endpoint automatically tracks and connects to the active writer instance across regions, eliminating the need for manual connection updates and making regional failovers completely transparent to applications.
#Aurora
Amazon
Connecting to Amazon Aurora Global Database - Amazon Aurora
Learn about the endpoints you use to connect to Amazon Aurora Global Database.
👍6
Aurora Serverless v2 + scaling to 0 = настоящий ServerLess
https://aws.amazon.com/blogs/database/introducing-scaling-to-0-capacity-with-amazon-aurora-serverless-v2/
Как и для первой версии, теперь честный ServerLess доступен для Aurora Serverless v2. То есть можно скейлить в 0.
Отличный повод проапгрейдиться как минимум до PostgreSQL 13 и MySQL 3, если вы ещё нет, т.к. более старые не поддерживаются.
#Aurora #Serverless
https://aws.amazon.com/blogs/database/introducing-scaling-to-0-capacity-with-amazon-aurora-serverless-v2/
Как и для первой версии, теперь честный ServerLess доступен для Aurora Serverless v2. То есть можно скейлить в 0.
Отличный повод проапгрейдиться как минимум до PostgreSQL 13 и MySQL 3, если вы ещё нет, т.к. более старые не поддерживаются.
#Aurora #Serverless
Amazon
Introducing scaling to 0 capacity with Amazon Aurora Serverless v2 | Amazon Web Services
Amazon Aurora Serverless v2 now supports scaling capacity down to 0 ACUs, enabling you to optimize costs during periods of database inactivity. Aurora Serverless is an on-demand, auto scaling configuration of Aurora that automatically adjusts your database…
👍13❤2👏2
— А давайте придумаем новое название для Aurora Serverless v2?
— А давайте!
🆕 Aurora DSQL = multi-region Aurora Serverless v2
https://aws.amazon.com/blogs/database/introducing-amazon-aurora-dsql/
#Aurora
— А давайте!
🆕 Aurora DSQL = multi-region Aurora Serverless v2
https://aws.amazon.com/blogs/database/introducing-amazon-aurora-dsql/
#Aurora
Aurora DSQL — мечта разработчика
Главным событием re:Invent 2024 определённо является появление Aurora DSQL — новой инкарнации Aurora, как результат её 10 лет разработки.
С появления революционной DynamoDB в 2012-м каждый первый разработчик спрашивал — а можно нам такое же, с этими фичами, только Relational и лучше Postgres?
Теперь можно: Aurora DSQL = multi-region + active-active + serverless + strong-consistency.
Под капотом Aurora DSQL в реальности целый комбайн сервисов. Представьте, что каждый ваш запрос обрабатывается отдельной Лямбдой. С великолепными возможностями скейлинга, причём крайне эффективного и отдельным сервисом для хранилища, отделяя таким образом compute от storage.
А самое офигительное, что практически удалив кэширование (сделав его динамическим) и с использованием принципиально ускорившейся за последние годы сети, удалось сделать Aurora DSQL волшебным strongly consistent даже в контексте мульти-регион конфигурации.
Ещё не до конца разобрался, как AWS удалось победить проблему скорости света. 😀 Ведь при использовании регионов на разных сторонах Земли задержка будет в секунду просто на прохождение таких расстояний. Подожду Aurora DSQL Deep Dive видео с re:Invent 2024.
Вот хорошие статьи с подкапотными деталями Aurora DSQL:
🔸 https://blog.datachef.co/aurora-dsql-a-new-boring-aws-serverless-postgres-compatible-database
🔹 https://brooker.co.za/blog/2024/12/04/inside-dsql.html
Добавляйте свои мысли/ссылки по Aurora DSQL в комментариях.
P.S. Aurora DSQL заявлена как "serverless", но не подразумевает скейла в 0. Как минимум это справедливо для текущей версии.
#Aurora
Главным событием re:Invent 2024 определённо является появление Aurora DSQL — новой инкарнации Aurora, как результат её 10 лет разработки.
С появления революционной DynamoDB в 2012-м каждый первый разработчик спрашивал — а можно нам такое же, с этими фичами, только Relational и лучше Postgres?
Теперь можно: Aurora DSQL = multi-region + active-active + serverless + strong-consistency.
Под капотом Aurora DSQL в реальности целый комбайн сервисов. Представьте, что каждый ваш запрос обрабатывается отдельной Лямбдой. С великолепными возможностями скейлинга, причём крайне эффективного и отдельным сервисом для хранилища, отделяя таким образом compute от storage.
А самое офигительное, что практически удалив кэширование (сделав его динамическим) и с использованием принципиально ускорившейся за последние годы сети, удалось сделать Aurora DSQL волшебным strongly consistent даже в контексте мульти-регион конфигурации.
Ещё не до конца разобрался, как AWS удалось победить проблему скорости света. 😀 Ведь при использовании регионов на разных сторонах Земли задержка будет в секунду просто на прохождение таких расстояний. Подожду Aurora DSQL Deep Dive видео с re:Invent 2024.
Вот хорошие статьи с подкапотными деталями Aurora DSQL:
🔸 https://blog.datachef.co/aurora-dsql-a-new-boring-aws-serverless-postgres-compatible-database
🔹 https://brooker.co.za/blog/2024/12/04/inside-dsql.html
Добавляйте свои мысли/ссылки по Aurora DSQL в комментариях.
P.S. Aurora DSQL заявлена как "serverless", но не подразумевает скейла в 0. Как минимум это справедливо для текущей версии.
#Aurora
DataChef's Blog
Aurora DSQL - A NEW boring(?) AWS Serverless Postgres compatible database
Aurora DSQL is a serverless, distributed database with PostgreSQL compatibility. Serverless and relational databases don't usually mix, but AWS has modernized this traditional classic car(PostgresSQL), with a brand-new interior powered by a Formula 1...
👍15❤2🔥2😱2
Forwarded from Make. Build. Break. Reflect.
#aws #aurora #terraform #finops
Материал уровня senior
Мы умеем определять тип инстанса - по нагрузке на CPU/Memory и другим факторам.
Но насколько эффективно мы выбрали
Эффективно ли это спустя год или два?
А никто не знает, давайте разбираться.
- сперва пилим Dashboard к нашему существующему кластеру
https://gist.github.com/kruchkov-alexandr/d9335d7927e58d06557b994dc9f194de
- применяем, видим панель в CloudWatch
Сверху у нас панель чтения/записи хранилища, снизу размер базы данных (+снепшоты?).
Разделение нужно из-за разницы масштабов и удобства экспорта.
- выбираем период три месяца и кликаем на трех точках у обоих панелей и выбираем
- заходим в cost explorer и экспортируем дату за три месяца по кластеру
- заходим в вашу любимую AI(я спрашивал у клаудии, перплексити и грок3, все платные) и пилим промт нечто типа(можете писать свой, если мой вам кажется тупым):
"Help me decide if we should switch to Amazon Aurora I/O-Optimized. Use the attached billing screenshot/csv, three-month IOPS data from the CSV, and the IOPS/storage graphs to analyze our costs. Calculate our current I/O expenses, compare them to I/O-Optimized costs and check if our I/O costs exceed AWS’s 25% threshold for switching. Look at IOPS and storage trends, then recommend whether to switch, including specific cost figures. I’ve attached all files (billing, CSV, graphs).
based on this article
https://aws.amazon.com/blogs/database/estimate-cost-savings-for-the-amazon-aurora-i-o-optimized-feature-using-amazon-cloudwatch/"
- ждём ответа и все 4 нейронки мне выдали на 95% одинаковый подробнейший расчёт ответ. Вкратце "
- пишем менеджеру/боссу
I've analyzed our infrastructure costs over the last three months billing and IOPS data, to see if switching to Amazon Aurora I/O-Optimized makes sense. Right now, it's not cost-effective. Our I/O costs an average of $******* monthly (************ I/Os at $**** per million). Moving to I/O-Optimized would increase instance costs by ***%, from $******* to $******* - a $******* jump, which is $415.21 more than our current I/O expenses.
Our IOPS trends show peaks up to *** but no major growth, averaging ~** Write and ~**** Read IOPS hourly in February. Storage usage is growing at *** GB/month, but that doesn't impact the I/O-Optimized cost comparison. AWS suggests I/O-Optimized when I/O costs exceed **% of total Aurora spend, but ours ($******) are only **% of the $******* total, so we're below that threshold.
I recommend sticking with our standard configuration for now. We should keep monitoring I/O activity -if it exceeds **** I/Os monthly or I/O costs reach **% of our Aurora spend, we can revisit I/O-Optimized.
Прикладываем все файлы,скрины,расчёты.
- закрываем таску и трекаем время
Всё вышеописанное заняло у меня минут 15, а вот подготовительные работы(чтение про фичу, особенности, лимиты, как считать, написание борды, особенности биллинга и тп) почти половину дня.
* Если не верите ИИ, можете пересчитать вручную🐒
Дополнительные полезные ссылки(а вдруг вы мне не верите):
- анонс фичи
https://aws.amazon.com/about-aws/whats-new/2023/05/amazon-aurora-i-o-optimized/
- обзор менеджер уровня
https://aws.amazon.com/awstv/watch/b9bfc040ac5/
- пример расчётов (там руками считают, без ИИ)
https://aws.amazon.com/blogs/database/estimate-cost-savings-for-the-amazon-aurora-i-o-optimized-feature-using-amazon-cloudwatch/
Материал уровня senior
Мы умеем определять тип инстанса - по нагрузке на CPU/Memory и другим факторам.
Но насколько эффективно мы выбрали
Cluster storage configuration Авроры вашего проекта?Эффективно ли это спустя год или два?
А никто не знает, давайте разбираться.
- сперва пилим Dashboard к нашему существующему кластеру
https://gist.github.com/kruchkov-alexandr/d9335d7927e58d06557b994dc9f194de
- применяем, видим панель в CloudWatch
Сверху у нас панель чтения/записи хранилища, снизу размер базы данных (+снепшоты?).
Разделение нужно из-за разницы масштабов и удобства экспорта.
- выбираем период три месяца и кликаем на трех точках у обоих панелей и выбираем
Download as .csv и качаем оба файла- заходим в cost explorer и экспортируем дату за три месяца по кластеру
- заходим в вашу любимую AI(я спрашивал у клаудии, перплексити и грок3, все платные) и пилим промт нечто типа(можете писать свой, если мой вам кажется тупым):
"Help me decide if we should switch to Amazon Aurora I/O-Optimized. Use the attached billing screenshot/csv, three-month IOPS data from the CSV, and the IOPS/storage graphs to analyze our costs. Calculate our current I/O expenses, compare them to I/O-Optimized costs and check if our I/O costs exceed AWS’s 25% threshold for switching. Look at IOPS and storage trends, then recommend whether to switch, including specific cost figures. I’ve attached all files (billing, CSV, graphs).
based on this article
https://aws.amazon.com/blogs/database/estimate-cost-savings-for-the-amazon-aurora-i-o-optimized-feature-using-amazon-cloudwatch/"
- ждём ответа и все 4 нейронки мне выдали на 95% одинаковый подробнейший расчёт ответ. Вкратце "
Переходить пока рано".- пишем менеджеру/боссу
I've analyzed our infrastructure costs over the last three months billing and IOPS data, to see if switching to Amazon Aurora I/O-Optimized makes sense. Right now, it's not cost-effective. Our I/O costs an average of $******* monthly (************ I/Os at $**** per million). Moving to I/O-Optimized would increase instance costs by ***%, from $******* to $******* - a $******* jump, which is $415.21 more than our current I/O expenses.
Our IOPS trends show peaks up to *** but no major growth, averaging ~** Write and ~**** Read IOPS hourly in February. Storage usage is growing at *** GB/month, but that doesn't impact the I/O-Optimized cost comparison. AWS suggests I/O-Optimized when I/O costs exceed **% of total Aurora spend, but ours ($******) are only **% of the $******* total, so we're below that threshold.
I recommend sticking with our standard configuration for now. We should keep monitoring I/O activity -if it exceeds **** I/Os monthly or I/O costs reach **% of our Aurora spend, we can revisit I/O-Optimized.
Прикладываем все файлы,скрины,расчёты.
- закрываем таску и трекаем время
Всё вышеописанное заняло у меня минут 15, а вот подготовительные работы(чтение про фичу, особенности, лимиты, как считать, написание борды, особенности биллинга и тп) почти половину дня.
* Если не верите ИИ, можете пересчитать вручную
Дополнительные полезные ссылки(а вдруг вы мне не верите):
- анонс фичи
https://aws.amazon.com/about-aws/whats-new/2023/05/amazon-aurora-i-o-optimized/
- обзор менеджер уровня
https://aws.amazon.com/awstv/watch/b9bfc040ac5/
- пример расчётов (там руками считают, без ИИ)
https://aws.amazon.com/blogs/database/estimate-cost-savings-for-the-amazon-aurora-i-o-optimized-feature-using-amazon-cloudwatch/
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21👍3🤔2❤1👏1
Миграция 4 миллионов баз на 3000 RDS в 13 регионах на Aurora:
https://www.atlassian.com/blog/atlassian-engineering/migrating-jira-database-platform-to-aws-aurora
#RDS #Aurora
https://www.atlassian.com/blog/atlassian-engineering/migrating-jira-database-platform-to-aws-aurora
#RDS #Aurora
Work Life by Atlassian
Migrating the Jira Database Platform to AWS Aurora
Explore how Atlassian successfully migrated four million Jira databases to AWS Aurora, overcoming unique technical and operational challenges at massive scale. Learn how the team balanced reliability, performance, and ambitious cost-saving goals—while minimizing…
🔥15👍9❤1😱1