Aurora MySQLとRedshiftのゼロETL統合が本番導入出来るか検証しました - クラウドワークス エンジニアブログ
Aurora MySQL Zero ETL Integrations クラウドワークスのSREチームに所属しています@ciloholicです。 2023年11月にAurora MySQLとRedshiftのゼロETL統合がGAされました。この度、ゼロETL統合が本番導入可能かを検証する機会があったので、その検証結果を記載します。 aws.amazon.com 2024年7月時点での検証結果ですので、時間経過によって内容が変わっている可能性があります。その点は十分ご注意ください。 背景 まず、ゼロETL統合の検証しようと考えた背景について軽く説明したいと思います。クラウドワークスでは、MySQLのテーブルをDMS経由でRedshiftにニアリアルタイムで同期し、データ分析を行なっています。3年前は約30億レコードでしたが、現在では古いレコードの削減を行なったため、約25億レコードになりました
DMM.com が Amazon Aurora MySQL に移行して、最大 70% のパフォーマンス向上と運用コストの大幅削減を実現 | Amazon Web Services
Amazon Web Services ブログ DMM.com が Amazon Aurora MySQL に移行して、最大 70% のパフォーマンス向上と運用コストの大幅削減を実現 DMM.com は動画配信事業とオンラインゲーム事業、FX 等の金融サービスを主力として、オンライン英会話サービスなど 60 以上のサービスを展開している企業です。DMM.com では、オンプレミスの MySQL で稼働していたユーザーレビュー機能を、Aurora MySQL に移行しています。データの移行は AWS Database Migration Service (DMS) を使用してダウンタイムを最小限に抑えつつ、移行元への逆同期や SageMaker を使用したデータ検証の仕組みなど、様々な工夫をしながら移行を成功させることができました。本ブログでは、DMM.com でオンプレミスの MySQL
AWS DMSでMySQLからRedshiftへのマイグレーションを試してみる - Qiita
諸条件 ソースがMySQLの場合、Redshiftへの変換にSCTが利用できない DMSにはSCT(SchemaConversionTool)という、ローカルPCにインストールしてスキーマやストアドプロシージャ等を自動変換・診断してくれるツールがあります。このSCTはソースDBとターゲットDBの組み合わせごとに使用可否が決まっている点に注意が必要です。 以下のURLの通り、ソースがMySQLの場合、ターゲットにRedshiftを選択することができません。 https://docs.aws.amazon.com/SchemaConversionTool/latest/userguide/CHAP_Welcome.html そもそもターゲットがRedshiftの場合は、ソースの対応DBエンジンにOLTP系のものは少なく、多くがOLAP系です。 OLTP系：SQL Server, Oracle
ロギングタスク設定 - AWS データベース移行サービス
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 ロギングタスク設定 ロギング機能は、移行プロセス中に Amazon CloudWatch を使用して情報をログします。ロギングタスク設定を使用して、記録するコンポーネントアクティビティと、ログに書き込まれる情報量を指定できます。ログ記録タスク設定は JSON ファイルに書き込まれます。タスク設定ファイルを使用してタスク設定を設定する方法については、「タスク設定例」をご参照ください。 CloudWatch ログ記録は、いくつかの方法で有効にできます。移行タスクを作成する AWS Management Console ときに、 で EnableLoggingオプションを選択できます。または、 AWS DMS API を使用してタスクを作成するtrueときに、 Enabl
クロスアカウントでの暗号化したRDSのスナップショット利用には気をつけようという話 - LIVESENSE ENGINEER BLOG
これは Livesense Advent Calendar 2022 DAY 4 の記事です。 こんにちは。アルバイト事業部エンジニアの@mnmandahalfです。 今日は先日開催された社内LT大会で話したネタを記事にしてみたいと思います。 VPoEだけが追い出された？！エンジニアLT大会を開催した話 - LIVESENSE ENGINEER BLOG TL;DR クロスアカウントで暗号化したRDSスナップショットを共有するときはCMKで暗号化した方がベター CMKを作るときのキーポリシーに注意しよう やりたかったこと ざっくり説明すると、以下の通りです。 本番環境（以下、AWSのproductionアカウント）のDBデータをステージング環境（以下、AWSのstagingアカウント）に日次で同期して利用したい その際、個人情報等にアクセスできないようにマスキング処理（例：データの削除、改
はてなブログの DB を RDS for MySQL 8.0 にアップグレードした話 - Hatena Developer Blog
この記事は、はてなエンジニア Advent Calendar 2023の2024年1月17日の記事です。 はてなエンジニア Advent Calendar 2023 - Hatena Developer Blog id:hagihala です。先日、はてなブログの DB を RDS for MySQL 5.7 から 8.0 へアップグレードしたので、工夫した点などを共有します。 Aurora MySQL 3.x にしなかった理由 MySQL 5.7 -> 8.0 で対応した変更点 character set や collation のデフォルトが変更される explicit_defaults_for_timestamp がデフォルトで有効になる SQL mode の変更 デフォルトの認証プラグインが caching_sha2_password になり、 mysql_native_passw
MySQL 5.7 to 8 check list
mysql57to8.md 確認すること メンテナンス時間をどれくらい取れるかで戦略が決まる。 基本的にはメンテナンス時間を十分に取れたほうが良い。 またリスクをどれだけ許容できるかもビジネスによるので要確認しておくべき。 基本的には一度切り替えてしまうとロールバックすることは簡単ではない。 覚悟を決めて突き進む必要がある 最初に諦めること MyISAMを使いたい 8でも動くけど諦めろ、もう未来はない InnoDBのほうがDisk サイズを消費する、countが遅い、などの課題はあるので簡単ではないが… InnoDB memcached Pluginとか使ってるんだよね 諦めろ、未来はない これを機にアーキテクチャを見直しましょう PKが無いtableがあるんだよね すべてのtableにまずPKを付けるんだ このあと、DMSを使ったりとかなにをするにしても死ぬ そもそもデータモデルとして死
MySQL5.7系からMySQL8.0系にアップグレードする際の破壊的変更を回避するために
Photo by Rubaitul Azad on Unsplashはじめにこんにちは、2021年4月にFinatextに新卒で入社し、まもなく3年目になる です。サーバーサイドエンジニアとして、AWSでのインフラ構築とGoによるシステム開発を行っています。 先日、MySQL5.7系互換であるAmazon Aurora v2を使用していたリリース前のプロダクトのデータベースを、MySQL8.0系互換であるAmazon Aurora v3にアップグレードした際に、予期せぬバグが発生しました。調べたところ、MySQL5.7から8.0へのアップグレードに含まれていた破壊的変更点によるものでした。 そこで、今回のバグから得た学びと対応方法について書きたいと思います。現在稼働しているシステムに対して、MySQL5.7系から8.0系にアップグレードをすることを検討していて、外部キー制約を使っている人の
Amazon Aurora MySQL DB クラスターのメジャーバージョンのアップグレード - Amazon Aurora
3.04.1 などの Aurora MySQL バージョン番号では、3 がメジャーバージョンを表します。Aurora MySQL バージョン 2 は MySQL 5.7 との互換性があります。Aurora MySQL バージョン 3 は MySQL 8.0 との互換性があります。 メジャーバージョン間のアップグレードでは、マイナーバージョンよりも広範な計画とテストが必要です。このプロセスにはかなりの時間がかかることがあります。アップグレードの完了後に、フォローアップ作業が必要な場合もあります。例えば、これは SQL 互換性の違いや、特定の MySQL 関連機能の動作方法の違いが原因で発生する可能性があります。または、古いバージョンと新しいバージョンでパラメータ設定が異なることが原因である可能性があります。 Aurora MySQL バージョン 2 からバージョン 3 へのアップグレード M
サーバー、データベース、インフラに関するトピックス
１.アップグレードの意義 バージョンアップを行うことは、パフォーマンスの向上、新機能の追加、セキュリティの強化など、それぞれに意義がある。 特にセキュリティに関しては、バージョンアップを行わないと、脆弱性に関するパッチを充てられない。 安全にWeb開発を行うためにも、サポート期限が切れる前にバージョンアップは行おう。 ２.デフォルトの文字コードの変更 MySQL8から、デフォルトの文字コードがutf8mb4になった。 これにより、絵文字や幾つかの特殊な文字を保存できるようになった。 これらはメリットではあるが、絵文字や特殊な文字を使わないという方は、 今まで通り使用していた文字コードを指定して、過去のデータベースと互換性を保つ方が良いだろう。 加えて、defaultのcharacter setで設定していた人は、 今まで使っていた文字コードと変わってしまうので、自分で以前使っていた文字コー
MySQL 5.7 から 8.0 にしたらテストが激遅になった - Qiita
この記事は、株式会社カオナビ Advent Calendar 2023 の3日目です。 はじめに 株式会社カオナビの高橋(@kunit)です。 今回は MySQL バージョンアップ(5.7 -> 8.0) で起きた問題とそれに対してどのように対処したのかを書いていこうと思います。 何が起きたのか MySQL 5.7 から 8.0 にバージョンアップをするにあたって、CI およびローカル環境でテストができるように MySQL 8.0 のイメージを作成し、それをつかって各機能の担当者にテストを開始してもらっていたのですが、以下のような事が起きました。 接続を MySQL 5.7 から 8.0 に切り替えただけでテストの時間が3倍くらいかかるようになった そこを変更するだけで3倍遅くなるってやばいぞということで報告してくれた担当者と同じテストを自分でも実施してみると再現性があり、それが以下のどの
MySQL 8.0 への移行が完了しました ～さようなら全ての MySQL 5.7～ - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。クラウド運用チームの飯塚です。 私たちは cybozu.com 本番環境の MySQL を昨年末から順次 8.0 系へアップグレードしており、前回の定期メンテナンスにおいて全てのインスタンスのアップグレードを完了しました。この記事では、私たちが MySQL 8.0 への移行に取り組んだ理由と必要になった対応について紹介します。 なぜ MySQL 8.0 へ移行したのか GTID-based レプリケーションにおける制限の緩和 再起動時に AUTO_INCREMENT のカウンタが巻き戻る問題の解消 実際に対応が必要だった MySQL 8.0 の変更点 utf8mb4 の照合順序のデフォルト値の変更 SQL_CALC_FOUND_ROWS と FOUND_ROWS() が deprecated に Connector/J のメタデータ取得処理の性能低下 sys.innodb_lo
位置情報系RubiestがMySQLを5.7から8.0にした話 - Qiita
静岡市でWeb開発しているkazuomatzです。 以前、こちらの記事で、Rails + MySQL で位置情報を扱う時に標準だったライブラリ activerecord-mysql2spatial-adapterについて書きました。 ライブラリの開発が止まってしまい、新しいRailsのバージョンに更新しようとすると対応されていないので、リポジトリをforkして、Rails6.0で何とか動かした話です。 今年、AWSのRDSのMySQL5.7系のサポートの終了がアナウンスされました。2024年2月以降、RDSでMySQL5.7を利用し続けるには、有償の延長サポートに入る必要があります。 というわけで今年は、MySQL5.7で稼働しているシステムをMySQL8に更新するお仕事が数件ありました（2023年12月現在、まだまだ絶賛実施中です）。 当然、MySQL5.7とMySQL8.0に移行するに
【RailsサービスのMySQL5.7 -> 8移行: 前編】MySQLのcollation周りの話 - hacomono TECH BLOG
この記事は、hacomono Advent Calender 2023の20日目の記事です。 はじめに こんにちは、プラットフォームチーム所属のまこたすです。 この記事は主にMySQL5.7,MySQL8.0のcollation周りの挙動の違いについて書いています。AWS RDS MySQL5.7がEOLを迎える今、一番話したい内容はRails x MySQL5.7環境からRails x MySQL8.0環境へ移行する際にハマった話とそこからみる気をつけるべき観点という話題ではあるのですが、前提の話が長いので記事を２つに分けてお伝えします。今回はRailsの話は触れず、MySQLのcollation周りの話のみをします。 この記事で書くこと MySQL5.7, MySQL8.0でのサーバー, データベース, テーブルのcollationの決まり方とSHOW CREATE (TABLE|DA
rails mysql5.7から8.0アップグレード時の注意点📝
railsが参照しているrdsをmysql5.7から8.0にアップグレードした時の注意点メモ utf8mb4を指定した場合は以下のパラメーターグループをutf8mb4にする必要がある character_set_database データベースの文字セットを定義します。文字セットは、文字を数値で表現する方法を定義するデータエンコーディングの一種です。 この設定は、新しく作成されるテーブルとそのカラムに使用されるデフォルトの文字セットを指定します。特定のテーブルやカラムに対して異なる文字セットを設定することも可能ですが、character_set_databaseはデフォルトの設定で、特定でない指定がない場合はこれが適用されます。 character_set_client ユーザーからのSQLステートメントがエンコードされている方法を定義します。クライアントからデータベースサーバーに送信される
AWS Database Migration Service との統合 AWS Schema Conversion Tool - AWS Schema Conversion Tool
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 AWS Database Migration Service との統合 AWS Schema Conversion Tool での AWS SCT レプリケーションエージェントの使用 AWS DMS 非常に大規模なデータベース移行では、 AWS SCT レプリケーションエージェント (aws-schema-conversion-tool-dms-agent) を使用して、オンプレミスデータベースから Amazon S3 または AWS Snowball Edge Edge デバイスにデータをコピーできます。レプリケーションエージェントは と連携して動作 AWS DMS し、 AWS SCT が閉じている間はバックグラウンドで動作できます。 AWS Snowball
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Migrating databases to their Amazon RDS equivalents with AWS DMS - AWS Database Migration Service
Converting database schemas using DMS Schema Conversion - AWS Database Migration Service
Using the AWS DMS Fleet Advisor Target Recommendations feature - AWS Database Migration Service
MySQL 8.0への移行を考える
