大きなテーブルのスキーマ変更を RDS Blue/Greenデプロイでダウンタイムなく実行 & マイグレーションとも辻褄を合わせる
はじめに 今回大きなテーブルのスキーマ変更のためにマイグレーションを実行したかったのですが、通常のデプロイフローでは対応できず試行錯誤しました。 最終的に、RDS Blue/Greenデプロイを活用しGreen環境でALTER TABLEすることでほぼダウンタイムなく対応できました。Railsのマイグレーションファイルの偽装方法も含め、道のりを記載します。 テーブルは2つあり、それぞれ 約2.5億レコードと約4000万レコード です。 show table status; +------------------------------+--------+---------+------------+-----------+ | Name | Engine | Version | Row_format | Rows | +------------------------------+----
【RDS Blue/Greenデプロイ】Green環境でスキーマ変更や書き込みをする方法と注意点
はじめに RDS Blue/Greenデプロイを使用すると、インスタンスの変更やDBエンジンのバージョンアップ、ファイルシステム設定のアップグレード、パラメータの変更等をダウンタイムを最小限に抑えて実行することができ、とても便利ですよね。 今回、データベースのカラム型変更（string型→text型）をしたく、Blue/GreenデプロイのGreen環境のMySQLでALTER TABLEやレコード追加を行ったのですが、無条件でなんでもGreen環境に変更を加えられるわけではないということを学びました。（よく考えればそりゃそうだ） Green環境で書き込みする方法と、その際の注意点を記載します。 Green環境の大前提 Green環境はBlue環境からレプリケーションされている -- AWSドキュメント グリーン環境はステージング環境です。ステージング環境は、論理レプリケーションを使用して
[小ネタ] RDSのMulti-AZ構成を切り替える手順 | DevelopersIO
しばたです。 例えばですが、システム開発においてRDSを利用するにあたり開発期間中はSingle-AZ構成にしてランニングコストを節約、受入テストや本番稼働の際にMulti-AZにして可用性を確保するといった運用は良くあるかと思います。 本記事ではこういった場合のためにRDSのMulti-AZ構成を切り替える手順について解説します。 検証環境 本記事では私が慣れているRDS for Oracle(Oracle 19c SE2, db.m5.large)で説明します。 他のRDBMSでも基本同様の手順となります。 また、RDSを構成するネットワーク設定およびRDSインスタンス自体は構築済みの前提です。 1. Multi-AZ構成からSingle-AZ構成に変更する まずはMulit-AZ構成の環境をSingle-AZ構成にする方法を紹介します。 最初にマネジメントコンソールからRDSサービス
![[小ネタ] RDSのMulti-AZ構成を切り替える手順 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/3b6eedbd02faf420a06aa05ca78d478cfa7b4cca/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Famazon-rds.png)
AWS RDS/AuroraのDDL運用を最適化する | 外道父の匠
AWS re:Invent 2022 にて RDS の Blue/Green が発表されたことを受けて、この辺の具体的な運用をどのように改善できるのか考えていきます。 たいした内容ではないですが、丁寧に最適化して慣れれば、それなりに強い効果を発揮できそうな感じはあります。 ALTER TABLE の辛み まず復習からですが、RDS に Blue/Green が実装されるほど辛い運用はなんだったかというと、重い ALTER TABLE にあります。 ALTER には色々あるのでアレですが大雑把に言うと、容量や行数が大きいテーブルに対して実行すると、数時間単位～の処理時間がかかることが多く、しかもパッと見で進捗を把握できないという問題を抱えていました。それに対して色んな対策を取っていたと思います。例えば…… Handler_write SHOW GLOBAL STATUS LIKE ‘Hand
サービスが急成長してRDSで困ってる君へ8000万件のテーブルをダウンタイム1時間でALTERするよ! - Qiita
サービスが急成長してRDSで困ってる君へ8000万件のテーブルをダウンタイム1時間でALTERするよ!MySQLインフラDatabaseメンテナンス サービスの急成長は嬉しいお知らせですが、その反面機能追加時のALTERがどんどん大変に。普通にALTERを行うと、メンテナンス時間何時間とったら、良いのかわからないですよね。１時間程度のメンテナンス時間で、RDS上のデカイテーブルをALTERする方法を紹介します。 戦略 1.リードレプリカを追加する 2.オンラインでリードレプリカにALTER文を実行 3.レプリケーションがおいつたタイミングで、アプリケーションの向き先をリードレプリカに変更 4.リードレプリカをマスターに昇格させる 手順 1.リードレプリカに書き込み権限を与える デフォルトの状態では、「Parameter Groups」のread_onlyが{TrueIfReplica}にな
Amazon RDSのBlue/Green Deploymentsを使ってMySQLのアップグレードをやってみる～調査編～ - WILLGATE TECH BLOG
弊社で利用しているMySQLのバージョンをMySQL5.7からMySQL8にアップグレードを行いました。その際に Blue/Green Deploymentsを使って実施する際にに調べた事をまとめて紹介したいと思います。 Blue/Green Deploymentsとは 制限事項 公式情報 検証した方々の情報 実際に検証をしてみてわかったこと 検証を踏まえて、実施する際にチェックする箇所 まとめ Blue/Green Deploymentsとは 現状の本番環境（Blue）を別に新しい本番環境（Green）を構築した上で接続先を切り替えるなどして新しい本番環境をリリースする運用方法です。 利点として システムのダウンタイムを短くできる ロールバックが容易 が挙げられます。 Amazon RDS Blue/Green Deploymentsの仕組みとしては、本稼働環境(以下Blue環境)と本稼
Amazon RDS Blue/Green Deployments を使っててハマったこと | NHN テコラス Tech Blog | AWS、機械学習、IoTなどの技術ブログ
はじめに Blue/Green Deployments でマイナーバージョンアップグレードを実施するために検証をした際に色々とハマったのでまとめました。 結構躓きましたが、今回は調べてもでてこなかったものを 2 つピックアップしています。 Blue/Green Deployments を使ってみた感想としては、かなり便利ですが、リリースされて間もない機能なのでまだ今後に期待という感じです。 なお、本記事では Blue/Green Deployments のユースケースや詳細については解説しません。 ユースケースや詳細については以下記事をご覧ください。 その 1. RDS Proxy が紐づいていると環境作成できない RDS Proxy が紐づいている Aurora クラスターに対して、Blue/Green Deployments を作成しようとするとエラーが表示されました。 原因:RDS
RDS Blue/Green Deployments を使ってシュッと utf8mb4 にマイグレーションした話 - カミナシ エンジニアブログ
こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシでは RDB に Amazon Aurora MySQL 2（MySQL 5.7 互換）を使っています（以下 Aurora MySQL と略します）。 ある日、社内の Slack で「𠮷」などの文字列が登録できないのではないかという話が出ました。これを聞いて「あー」と思った方も多いでしょう。 MySQL で有名な UTF-8 の 4 バイト文字問題で、歴史的な理由から MySQL 5.7 以前では utf8 の文字セットは utf8mb4 ではなく utf8mb3 を指しています。 dev.mysql.com カミナシのアプリケーションは 4 バイトの文字列が入力された場合はシステムエラーを返す実装になっていますが、エラーの内容をユーザーにわかりやすく伝えることは難しいためユーザー体験としても良くない
RDS インスタンスのメジャーバージョンのアップグレード - Qiita
メジャーバージョンのアップグレード 商用環境への適用前に、いずれのアップグレードも徹底的にテストすること。 メジャーバージョンアップグレード中、必要に応じて RDS によって MySQL バイナリ mysql_upgrade が実行され、テーブルがアップグレードされます。 メジャーバージョンアップグレード中、RDS によって slow_log および general_log テーブルが空にされます。これらのログ情報を保持するには、メジャーバージョンアップグレードの前にログファイルの内容を保存する。 通常は約 10 分で完了するが、インスタンスタイプによる。 MySQL 5.7 から 8.0 へのアップグレードの事前チェック MySQL 8.0 には 5.7 との非互換性がいくつかある。 MySQL 5.7 から 8.0 へのアップグレードをスタートすると、RDS では、これらの非互換性を検
AWSのRDSでブルー／グリーンデプロイ - 株式会社ブースターテクノロジー
AWSからRDSのバージョンアップをしろという通知が来た。 MySQL5.7 のサポートが終わるから8系にしてね、更新しない場合は自動的に更新しちゃうよと。 今回はブルー／グリーンデプロイ方式でバージョンアップを行った。 （１）手順１ 対象のDBを選択し、「ブルー／グリーンデプロイの作成 – 新規」から後は普通にやればOK。 ブルー ⇒ 既存のMySQL 5.7.38 グリーン ⇒ 新しいMySQL 8.0.34 が出来上がる。グリーンの方は read only として作られた。 所要時間30分程度。 （２）手順２ ステージング環境のWebアプリのDB接続先をグリーンの方に向けて動作確認 （３）手順３ OKなら「切り替え」を行うことで、グリーンがブルーになる。 アプリケーション側は何もする必要なし。 所要時間5分程度。 （４）手順４ 本番環境で動作確認。 ※※ 注意！！ ※※ ついでにRD
AWS Amazon RDSのバージョンアップにBlue/Greenデプロイ機能を使ってみた - Qiita
内容 RDS AuroraのMySQLのバージョンをAurora2(MySQL5.7) ⇒ Aurora3(MySQL8.0)にアップデートする際、先日のre:Invent 2022で発表された「RDSのBlue/Greenデプロイ」という新しい機能を使用してみました。 今回その手順と、詰まったポイントをまとめていきたいと思います。 添付画像の網掛けが多い点はご容赦ください。 目次 Blue/Greenデプロイの概要 手順 スナップショットを取得 Blue/Greenデプロイの作成 GreenのDBに変更を加える 変更を加えたgreenのdbをテスト GreenをBlueに切り替え 完了 後始末 トラブルシューティング Blue/Greenデプロイの概要 Blue/Greenデプロイとは 現在運用中の環境をBlueとして、レプリケーションしたステージング環境（Green環境）を用意します。
Amazon RDS Blue/Green Deployments を色々と検証してみた！
こんにちは！ スターフェスティバルでインフラエンジニアをやっております @koonagiです。 早いことにもう1月も終わりますね。 1月のうちにブログを書こうと思っていたら、あっという間に終盤になってしまっていて急いでこの記事を書いていますｗ さて、先月のre:Inventでリリースされた Amazon RDS Blue/Green Deployments について、最近検証したのでそのことについて書いていこうと思います。 Aurora v1(MySQL 5.6)が2月末でサポート終了となるため、Aurora v2(MySQL 5.7)へのバージョンアップの際にAmazon RDS Blue/Green Deploymentsを活用しようと考えており、事前準備として検証を進めました。 Amazon RDS Blue/Green Deploymentsとは 公式からの引用です。 ブルー/グリ
MySQL DB エンジンのアップグレード - Amazon Relational Database Service
新しいバージョンのデータベースエンジンが Amazon RDS でサポートされている場合は、DB インスタンスをその新しいバージョンにアップグレードできます。MySQL データベースのアップグレードには、メジャーバージョンのアップグレードとマイナーバージョンのアップグレードの 2 種類があります。 メジャーバージョンのアップグレード メジャーバージョンのアップグレードには、既存のアプリケーションとの下位互換性のないデータベースの変更が含まれる場合があります。そのため、DB インスタンスのメジャーバージョンアップグレードは手動で実行する必要があります。メジャーバージョンアップグレードをスタートするには、DB インスタンスを変更します。メジャーバージョンのアップグレードを行う前に、「MySQL のメジャーバージョンのアップグレード」の手順を実行することをお勧めします。 マルチ AZ DB イン
【EOL間近】Amazon RDS for MySQL 5.7の標準サポート終了とバージョンアップ前の影響確認について - ForgeVision Engineer Blog
こんにちは。フォージビジョンの藤川と申します。 2023年9月初めに、AWSよりAmazon RDS for MySQL 5.7の標準サポート終了に関する内容と延長サポートに関する内容の通知がありました。以下は、2023/9/13時点のAWS公式サイトの情報です。 メール本文にも記載がありましたが、各々の情報は以下のAWS公式サイトに記載があります。 Amazon RDS for MySQL 5.7の標準サポート終了 2023/9/13時点では、表示言語を英語にすることで、標準サポート終了日の最新の情報や延長サポートの内容を確認することができました。 docs.aws.amazon.com Amazon AuroraとAmazon RDSがMySQLとPostgreSQLデータベースの延長サポートを発表 aws.amazon.com データベースのメジャーバージョンのアップデートについては
crowdworks.jpのマスタデータベースをAWS RDS MySQL 5.7から8.0にアップデートしました - クラウドワークス エンジニアブログ
こんにちは。crowdworks.jp SREチームの田中（kangaechu）です。 crowdworks.jpでは、2023年8月にAWS RDS MySQL 5.7から8.0へのアップデートが完了しました（ようやく！）。 今回はMySQL 8.0へのアップデートの手順と対応が必要な変更点について書いていきます。 MySQL 8.0にアップデートした理由 MySQL 8.0にアップデートした理由はAWS RDS MySQLのEOL対応のためです。 AWS RDS MySQL 5.7のEOLは2023年10月（のちに2023年12月に変更されました）であり、8.0へのアップデートが必要でした。 crowdworks.jpで使用している他のMySQLデータベースは8.0へのバージョンアップを完了していました。 しかしcrowdworks.jpのマスタデータベースは30億行を保持し、1日に約
【衝撃】AWSのRDSがデータを失わないBlue/Greenデプロイに対応しました #reinvent | DevelopersIO
「最近は、データベースもB/Gデプロイできるらしいよ？」 「そりゃそうやろ。B/Gデプロイなんて、最近当たり前……… へ？DBが？無理でしょ？ほぇ？どういうこと？」 最初アップデートのタイトルを見たときの、ハマコーの率直な感想です。 Blue/Greenデプロイは、現行バージョンのトラフィックを活かしたまま新バージョンを動作確認し、問題なければ新バージョンをリリースするという、最近の安全なデプロイの概念において無くてはならないものです。 同時に新旧バージョンを稼働させるため、基本的にはステートレスなアプリケーション・サーバーにおいて利用するものという固定概念があったのですが、それをデータベースに対して既存のAWSの技術を組み合わせつつAWSらしいマネージドな仕組みで解決しようという、意欲的なリリースです。制約事項もそれなりにあるので、皆さんの運用ワークロードに当てはまるかは、事前の検証が必
AWS RDS MySQL で create function できるようにする - Qiita
Amazon Web Service の RDS 上でのデフォルトでは、root であっても CREATE FUNCTION ... すると You do not have the SUPER privilege and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable) mysql> SHOW VARIABLES LIKE 'log_bin_trust_function_creators'; +---------------------------------+-------+ | Variable_name | Value | +---------------------------------+-------+ | log_
本番環境でダウンタイムを最小限にするためRDSをMulti-AZ構成にした後スケールアップを行う - Qiita
こんにちわ！OCEAN'Sの大庭です。 今回は、本番環境でRDSのスケールアップを行いましたのでその手順とログを紹介していきます 概要 まず、RDSがSingle-AZ構成のままスケールアップを行うと、 インスタンス停止 インスタンスタイプの変更（スケールアップ） インスタンス起動 となってしまい、DBサイズにもよるがサービスダウンタイムが10分弱はかかってしまいます。 そのため、今回は以下の方法でスケールアップを行います RDSをMulti-AZ構成に変更 RDSのスケールアップ プライマリにフェイルバック RDSをMulti−AZに変更 まず、RDSをMulti−AZ構成に変更する。 Multi-AZ構成への変更はダウンタイムが発生しませんが、 シングル AZ からマルチ AZ への変換時のダウンタイムを回避できますが、マルチ AZ への最初の変換時にパフォーマンスに大きな影響が出るこ
CactiでAmazon RDS for MySQLの性能監視 | 稲葉サーバーデザイン
※監視結果データはEC2インスタンスの/usr/share/cacti/rra/ に保存されます。すでに作成済みのRRDファイルは上記のように保存期間を変更しても反映されないため、別途rrdtoolコマンドでRRDファイルを修正する必要があります。このため、監視対象を追加する前に保存期間を延ばしておくとよいでしょう。 Cacti監視を開始 Cactiのcronエントリーのコメントアウトを外し、監視を開始します。 # vi /etc/cron.d/cacti -- */5 * * * * cacti /usr/bin/php /usr/share/cacti/poller.php > /dev/null 2>&1 -- これで、5分に一度監視データの取得を実行します。 グラフ表示の確認 WebブラウザでCacti Webページを表示します。 http://<EC2のホスト名またはIPアドレス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RDS から mysqldump するときのお作法 - AR ホームベーカリー
