並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 632件

新着順 人気順

MySQL-8.0の検索結果1 - 40 件 / 632件

  • Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス

    読者対象 ある程度データベースに関する知識を持っている,経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため,すべての SQL 使用者を対象とする また,ゼロからの丁寧な説明というよりは,リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id (データ型と INSERT 時のデフォルト埋め) 導入 一般的に採用されやすいプライマリキー用の値として,以下を考える。 連番整数 MySQL では AUTO_INCREMENT, Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7(ドラフト): 単調増加であるタイムスタンプとラ

      Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス
    • サブクエリの書き方を2万文字弱かけてすべて解説する

      これはなに ども、レバテック開発部のもりたです。 今回はSQLのサブクエリについてまとめます。仕事でクエリを書く際、サブクエリは頻出の構文だと思うんですが、同時にサブクエリの書き方を完全に理解しているよという人は案外少ないのではないでしょうか?[1] 実際、MySQLの公式ドキュメントを見ると12ページくらいを割かれており、意外と奥深いのがサブクエリです。使いこなせると便利ですし、何よりちょっとSQLのコツみたいなのがわかって面白いよ、ということで記事にしてみました。 前提 この記事は以下の前提を含んでいます。 環境 MySQL8.0系 読者の知識 なんとなくサブクエリが書ける けど相関サブクエリとかになると「あーっ」つってGoogle meetを閉じてしまうくらいのレベル感 記事のボリューム 18,000文字 おれの卒論が20,000文字だった マサカリ 間違ってたら投げてくれ〜〜 それ

        サブクエリの書き方を2万文字弱かけてすべて解説する
      • MySQL のレプリケーションから10年間逃げてきた我々が学んだこと8選 - Cybozu Inside Out | サイボウズエンジニアのブログ

        こんにちは。クラウド運用チームで SRE をしている飯塚です。 今回は、MySQL のレプリケーション機能を約10年もの間ずっと使ってこなかった私たちが、レプリケーションを使った高可用性構成に移行するための取り組みの中で学んだことについて紹介します。 背景 巨大なテーブルへの primary key の付与 トランザクションサイズが大きい場合には tmpdir に注意 mysqldump で絵文字が消えていないか要チェック mysqldump が Error 1412: Table definition has changed... で失敗する mysqldump したデータのリストアが Duplicate entry 'xxx-yyy-PRIMARY-n_diff_pfx01' for key 'PRIMARY' で失敗することがある mysqldump したデータのリストア時のディスク

          MySQL のレプリケーションから10年間逃げてきた我々が学んだこと8選 - Cybozu Inside Out | サイボウズエンジニアのブログ
        • GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる

          GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる GitHubが提供するGitHub.comは、世界最大のソースコード管理システムを始めとするソフトウェア開発者向け支援サービスを提供しています。 そのGitHub.comはRuby on Railsで構築されており、同社はつねにRubyとRuby on Railsをアップデートし続けていることを今年(2023年)4月に明らかにしています。 参考:GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている そして同社はこのGitHub.comを支える1200台以上のMySQL 5.7を、GitHub.comのサービスレベルを維持したまま1年以上かけてMySQL 8.0にアップグレードしたことをブログで明らかにしました。 Up

            GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる
          • データベースのロックの基礎からデッドロックまで

            データベースのロックについて、資料を読んだり実際に試してみたので、学んだことを整理してみようと思います。はじめにロックについての基本的な知識を整理して、最終的にはデッドロックとその対策について説明します。 使用したソフトウェアのバージョン MySQL 8.0.31 この記事ではMySQLを使用しています。その他のデータベースについては、基本的な部分は共通していると思いますが、異なる点があることをご了承ください。 ロックとは何か(概要) ロックはデータの更新を正しく行うための仕組みの一つで、あるデータに対する更新処理を制御するためのものです。ここで、データを正しく更新するとはどういうことかを説明するために、口座への振込を例に考えてみます。 例えば、口座Aから口座Bに1万円の振込を行うとします。このとき、口座Aの出金処理と口座Bの入金処理は、必ず両方が成功しなければなりません。このための仕組み

              データベースのロックの基礎からデッドロックまで
            • たぶんもう怖くないGit ~Git内部の仕組み~ - Qiita

              追記 先日外部向けに、この記事の内容に追加補足などを加えて発表しました。動画のアーカイブ、資料も公開しましたので、もし動画の方がわかりやすい方はこちらをオススメします。 注意: 動画の質疑の中で、 github のリリース機能が、アノテートタグを使っていると明言してしまいましたが、間違いです。gitのデータ上はただの軽量タグで、 release の内容は軽量タグに紐づく形で、 github のアプリケーション上で管理されているはずです。 はじめに 調べてもう1年放置していた内容なんですが、アドベントカレンダーで重い腰を上げました。 Gitの内部の仕組みを知りたい(動機) 毎日使うといってもいいGitですが、どうやって履歴を管理してるんだとか、よくわからないまま使っているのが急に怖くなりました。 Gitを触り始めで、よく以下のような疑問が沸くと思います。 どうやってGitは履歴を管理してるん

                たぶんもう怖くないGit ~Git内部の仕組み~ - Qiita
              • MySQLのインデックスの貼っていいとき悪いときを原理から理解したいよ😭

                今回答えを出したい問いはこちら!! インデックスはどのような仕組みを以て、何を実現したいものなのか それを踏まえたとき、インデックスはどういう場合になぜ貼る方が良いのか。また、どういう場合になぜ貼らない方が良いのか 大体分かっているよって人はサヨナラって感じのおさらい記事だぜ!!!!それじゃいってみよー🎉 あと、おれは今回MySQLにしぼっていくぜ👶 ってわけでOracleとかに興味があるやつは引き返しな! indexの概要 公式の見解としては「where句を使ったselectクエリの実行速度を向上させるために実装されている、各行へのポインターのような振る舞いをする仕組み」って感じ👶 The best way to improve the performance of SELECT operations is to create indexes on one or more of t

                  MySQLのインデックスの貼っていいとき悪いときを原理から理解したいよ😭
                • 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

                    MySQL 8.0 への移行が完了しました ~さようなら全ての MySQL 5.7~ - Cybozu Inside Out | サイボウズエンジニアのブログ
                  • 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 5.7 から 8.0 にしたらテストが激遅になった - Qiita
                    • CentOS 8 と CentOS 7 の違い、yum やミドルウェアにも要注意 - サーバー構築と設定 ~初心者にも分かりやすく解説~

                      2019年9月24日に CentOS 8 がリリースされます。 RedHat Enterprise Linux 8 の情報を元に、CentOS 8 で想定される変更点をまとめました。 PHP や MySQL といったミドルウェアのバージョン変更や、 サービスの追加・削除など数多くの変更が入ることになります。 RHEL 8・CentOS 8 に PHP 7.3 をインストールする(remi 使用) 2020-07-07 CentOS 8 のリリースは2019年9月24日 CentOS 8 はリリース前の状態で、現在コミュニティによる開発が行われています。 2019年7月時点では、ベースとなる「RHEL 8」のパッチ開発と検証作業が進行中です。 前回バージョンアップ時は、「RHEL 7」の27日後に「CentOS 7」がリリースされましたが、 今回の進捗を踏まえると 2019年8月~9月 頃の

                        CentOS 8 と CentOS 7 の違い、yum やミドルウェアにも要注意 - サーバー構築と設定 ~初心者にも分かりやすく解説~
                      • そろそろSQLのウィンドウ関数を理解したい - 連載1/3話 - Qiita

                        はじめに データ分析とデータ品質改善に従事してきた筆者が、SQLを用いた分析の基本である「ウィンドウ関数」の使い方とデータ品質の調査改善を行う手法をまとめてみようと思います。 こちらの記事は、SQLの知識向上と振り返りを主題としているので、ABC分析、バスケット分析、RFM分析などの「データ分析の手法」について説明している記事ではありません。(反響やコメントによって別投稿するかもしれません) 背景 SQLはエンジニアの大多数が利用しており、多くの方はWebサービス開発などでデータの登録画面や検索画面を作る際にSQLを利用したり、またはシステムの運用保守で障害の原因調査のためにSQLを利用して原因を特定すると思います。そのため、テーブル結合・サブクエリ・集計関数といったSQL構文は理解されている人が多いと思いますが、分析関数を理解して使っている人となると、ぐっと減ると思います。 私は以前、社

                          そろそろSQLのウィンドウ関数を理解したい - 連載1/3話 - Qiita
                        • オンライン DDL を期待して ALTER 文を実行したら障害になりかけた話 - カミナシ エンジニアブログ

                          こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 カミナシではマルチプロダクト化に向けて、認証・認可の切り出しを進めています。その対応を進める中で、既存テーブルへのカラム追加が必要になりました。 先日、そのリリースのために本番データベースにマイグレーションの ALTER 文を実行したところ、クエリが詰まって危うく障害になるところでした(幸いすぐにキャンセルして事なきを得ました)。 原因を調べたところ、オンライン DDL は複数の条件が関係することがわかりました。オンライン DDL に対する知識不足と事前検証の甘さゆえのミスでしたが、結果的には良い学びが得られました。 カミナシのバリューのひとつである「全開オープン」の気持ちで、事の顛末やそこから得た学びを公開します。 なお、今回の話は MySQL 5.7 互換の Amazon Aurora MySQL 2 で確

                            オンライン DDL を期待して ALTER 文を実行したら障害になりかけた話 - カミナシ エンジニアブログ
                          • MySQL で使用するメモリサイズの見積もり - 元RX-7乗りの適当な日々

                            最近、MySQLのパラメータの調整をする機会があったのですが、特定のパラメータを変更した際に、メモリの消費量にどう影響するのか、というのを調査する際に、インターネッツを彷徨ったところ、サイトによって書いてあることにバラつきがあったので、自分でもまとめてみることにした。 結論から書くと、参考にしたのは以下のオライリーの書籍「MySQLトラブルシューティング」で、記述が一番わかりやすく書かれていた。 このエントリは、この書籍の 「3.9.3 オプションの安全値を計算する」 にて記載がある内容をまとめたものになる。 MySQLトラブルシューティング 作者:Sveta SmirnovaオライリージャパンAmazon 著者について Sveta Smirnova(スヴェータ・スミルノヴァ): Oracle社MySQLサポートグループ・バグ検証グループの主席テクニカルサポートエンジニアとして毎日MySQ

                              MySQL で使用するメモリサイズの見積もり - 元RX-7乗りの適当な日々
                            • サイボウズさんの開運研修(データベース)で話してきました

                              2024 ( 17 ) 4月 ( 3 ) 3月 ( 6 ) 2月 ( 1 ) 1月 ( 7 ) 2023 ( 20 ) 12月 ( 3 ) 11月 ( 3 ) 10月 ( 1 ) 8月 ( 1 ) 5月 ( 2 ) 4月 ( 2 ) 3月 ( 3 ) 2月 ( 5 ) 2022 ( 27 ) 12月 ( 5 ) 10月 ( 1 ) 9月 ( 1 ) 8月 ( 5 ) 7月 ( 4 ) 6月 ( 3 ) 4月 ( 1 ) 3月 ( 3 ) 2月 ( 2 ) 1月 ( 2 ) 2021 ( 22 ) 12月 ( 4 ) 10月 ( 2 ) 9月 ( 6 ) 7月 ( 1 ) 6月 ( 3 ) 5月 ( 3 ) 東京都オープンデータカタログサイトのCSVを使ってLOAD DATA LOCAL INFILEの練習をする サイボウズさんの開運研修(データベース)で話してきました オプティマイザヒント

                              • MySQLのSQLクエリチューニングの要所を掴む勉強会を開催しました! - ANDPAD Tech Blog

                                こんにちは!DBREの福間(fkm_y)です。先月、弊社でデータベースの技術顧問をして頂いてる三谷(mita2)さんに開発本部向けの「MySQL SQLチューニング」勉強会を実施していただきました。 今回はMySQLの得意不得意なことの説明やSQLチューニングの流れ、具体的な事例を元にした対応例、また最近話題のHTAPな製品も紹介していただきとても参考になったのでポイントをおさえてレポートをお伝えします! 開催背景 本編 MySQL の得意なこと、苦手なこと データベースのチューニング手段と特徴 SQLチューニングの流れ インデックス SQLチューニング例 インデックスフルスキャンとカバーリングインデックス ソート まとめ 当日の資料 さいごに 過去開催されたデータベース勉強会レポート 開催背景 弊社では三谷さんによるデータベース勉強会を定期的に開催しています。数年前にも同じテーマで勉強会

                                  MySQLのSQLクエリチューニングの要所を掴む勉強会を開催しました! - ANDPAD Tech Blog
                                • MySQL/Aurora/TiDBロック入門 – 第1回トランザクション分離レベル|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ

                                  MySQL/Aurora/TiDBロック入門 – 第1回トランザクション分離レベル MySQL InnoDB および AWS Aurora や PingCAP TiDB におけるロックの仕組みやトランザクションの動作を全11回のシリーズで解説します! 最初はベースとして重要な MySQL 8.0 InnoDB 前提でユーザー視点でのロックの仕組みを学び、後半第10回以降では MySQL 互換 DB として人気の高い AWS Aurora や PingCAP TiDB と MySQL InnoDB との違いについて学びます。 1回目の今回はロック機構と切っても切り離せないトランザクションとその分離レベルについて、実際に挙動を確かめながら解説します。ライブ感のある説明も理解に役立ちますので、解説動画も付けてみました。合わせてご覧ください! ★ 第1回 トランザクション分離レベル ★ 第2回 ロ

                                    MySQL/Aurora/TiDBロック入門 – 第1回トランザクション分離レベル|技術ブログ|北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
                                  • DBスキーマ変更管理ツール sqldef を試してみた - Qiita

                                    1. sqldef とは sqldef は "The easiest idempotent MySQL/PostgreSQL/SQLite3/SQL Server schema management by SQL." と謳っているDBスキーマ変更管理ツールです。 通常の開発において DDL 文を管理する場合、環境を1から作るように CREATE TABLE 文など新規作成 DDL 文を準備すると共に、既に作成済みの環境でテーブルを変更するために ALTER TABLE 文など差分適用 DDL 文を準備する必要があります。この2種類の DDL 文を二重管理しないといけないというのは DBA にとっては頭の悩ましい問題でした。(差分適用 DDL 文のみ準備し、1から環境を作る場合も全ての変更を適用するという手もありますが…) sqldef を利用すると、変更適用先 DB の現在の状況と新規作成

                                      DBスキーマ変更管理ツール sqldef を試してみた - Qiita
                                    • いまさらDocker入門(AWS FargateでRails環境をつくる - その1) - 虎の穴開発室ブログ

                                      こんにちは、虎の穴ラボNSSです。 今まで私は、サーバーレスの勉強の一環として、AWS Lambdaを使ったWebアプリケーションの作成方法を、本ブログやとらラボの同人誌等で紹介してきました。 しかし、サーバーレスに関するサービスはAWS Lambdaだけではなく、他にもたくさんあります。 その中で今回は、AWS Fargate(以下Fargate)を使って、2020年5月時点の最新Rails開発環境をFargateで作って見たいと思います。 ...と思っていたのですが、Fargateを利用するには、いくつか前提となる知識が必要になることがわかりました。 前提となる知識は、 コンテナ・Dockerの知識 Amazon ECR、ECSの知識 Fargateの知識 などです。 全てを説明すると長くなってしまうので、何回かに分けて説明していきたいと思います。 何回になるかわかりませんが、最終的に

                                        いまさらDocker入門(AWS FargateでRails環境をつくる - その1) - 虎の穴開発室ブログ
                                      • M1Mac × Docker × SchemaSpy × MySQL8.0でテーブル定義書とER図を自動生成してみる

                                        M1Mac × Docker × SchemaSpy × MySQL8.0でテーブル定義書とER図を自動生成してみる 2022.10.19 技術 Docker, MYSQL こんにちは、システム部の能勢です。昨年の秋に入社して、今はバックエンドを中心に開発を担当しています。 「この設計資料、最終更新何年前やねん」 「なんか現実と違うんですけど」 こんな言葉にビビビっとくる方いませんか? 最近はかなり激減したんですが、自分は少なくともエンジニアキャリアの最初の方ではこういう経験をよくしてきたタイプです。 弊社みたいにプロジェクトリリース前にドキュメントを第三者視点できっちり確認されるような体制のある開発現場ではこういうことが起こるのも低頻度だと思うんですが、実際問題世の中にはいろんなタイプの現場がありますし、そこまできっちり管理しきれない・・・こんなホンネが漏れるのが実情という方も多いんじゃ

                                          M1Mac × Docker × SchemaSpy × MySQL8.0でテーブル定義書とER図を自動生成してみる
                                        • Herokuから ECSに 移行した - pixiv inside

                                          こんにちは、インフラ部の id:sue445 です。私事ですが先日GCPの Professional Cloud Architect を取得しました。 そういうわけで今日はGCPではなくAWSの話をします。 tl;dr; 劇的ビフォーアフター 構成 移行のモチベーション パフォーマンス向上 コスト圧縮 アーキテクチャの採択理由 やったこと 1. DB作成 2. MySQL 5.7 -> 8.0 MySQL 8.0でハマったこと MySQL 8.0からデフォルトの認証がcaching_sha2_passwordになった RDSのMySQL 8.0からMariaDB 監査プラグインがなくなった 3. 本番用のDockerイメージを作成 困ったこと:CodeIgniterがログの標準出力に対応していなかった 4. ECS + Fargate + CodePipeline構築 5. CDN作成 6

                                            Herokuから ECSに 移行した - pixiv inside
                                          • はてなブログの 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

                                              はてなブログの DB を RDS for MySQL 8.0 にアップグレードした話 - Hatena Developer Blog
                                            • Aurora MySQL でレコードが存在するのに SELECT すると Empty set が返ってくる事象を調査した話

                                              こんにちは。 KINTO テクノロジーズの DBRE チーム所属のp2skです。 DBRE(Database Reliability Engineering)チームでは、横断組織としてデータベースに関する課題解決や、組織のアジリティとガバナンスのバランスを取るためのプラットフォーム開発などを行なっております。DBRE は比較的新しい概念で、DBRE という組織がある会社も少なく、あったとしても取り組んでいる内容や考え方が異なるような、発展途上の非常に面白い領域です。 弊社における DBRE の取り組み例としては、あわっち(@_awache)による DBRE ガードレール構想の実現に向けた取り組みについてというテックブログや、今年の AWS Summit の登壇内容を是非ご覧ください。 今回の記事は、データベースに関する課題解決の事例として「Aurora MySQL でレコードが存在するのに

                                              • MySQL(InnoDB)のSQLパフォーマンスチューニングのエッセンス

                                                はじめに MySQL(InnoDB)でSQLのパフォーマンスチューニングをするときに役に立つ知識をエッセンスとしてまとめました。結合(JOIN)やB-treeインデックスの探索の仕組み、実行計画の基本的な見方を紹介します。 想定する読者は、SQLのパフォーマンスを改善する必要があるが実行計画をみてもいまいちピンと来ない方です。インデックスの作成の経験や、複合インデックスやカーディナリティの知識があることを前提にしています。目標は、実行計画の内容がよく分からない読者が、実行計画をみただけでクエリが実行される様子をイメージでき、自信を持ってクエリの改善にあたることができるようにすることです。 ストレージエンジンはInnoDBを前提としています。また、インデックスはB-treeインデックスを想定しています。全文検索の転置インデックスや空間検索のR-treeインデックスについては触れません。 イン

                                                  MySQL(InnoDB)のSQLパフォーマンスチューニングのエッセンス
                                                • MySQL8.0のバックアップはどれがいいのか - CyberAgent SRG #ca_srg

                                                  #SRG(Service Reliability Group)は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。

                                                    MySQL8.0のバックアップはどれがいいのか - CyberAgent SRG #ca_srg
                                                  • NestJSをゼロから学ぶ - TypeORMの活用などをREST APIの実装から身に付けよう【Node.jsフレームワークの基本】|ハイクラス転職・求人情報サイト AMBI(アンビ)

                                                    このようにさまざまなデコレータが用意されていますが、今回はサンプルで利用するデコレータに絞って説明します。他のデコレータについては、NestJSの公式ドキュメントなどを参照してください。 依存性注入(DI) 依存性注入(DI、Dependency Injection)とは、クラスの依存関係を解決する仕組みです。NestJSでは、依存性注入を使ってクラスの依存関係を解決します。 クラスの依存関係とは、クラスが他のクラスに依存している関係のことです。例えば、次のようなクラスAがあったとします。このクラスは他のクラスに依存していません。@Injectable()デコレータを使って、サービスを定義します。 @Injectable() class A { constructor() {} } そして、次のようなクラスBがあったとします。このクラスは、@Inject()デコレータを使って依存性を注入し

                                                      NestJSをゼロから学ぶ - TypeORMの活用などをREST APIの実装から身に付けよう【Node.jsフレームワークの基本】|ハイクラス転職・求人情報サイト AMBI(アンビ)
                                                    • Amazon Aurora MySQLでテーブル再構築を伴う操作をするとテーブルが見えなくなるっぽい - GMOインターネットグループ グループ研究開発本部(次世代システム研究室)

                                                      2023.01.11 Amazon Aurora MySQLでテーブル再構築を伴う操作をするとテーブルが見えなくなるっぽい Amazon Aurora MySQLでテーブルの再構築を伴う操作を行うと,Readerインスタンスで瞬間的に対象のテーブルが見えなくなる場合があるので,オペレーションの実行タイミングに気をけましょう,というお話です。再構築を伴う操作には,一部のALTER TABLEやOPTIMIZE TABLEが含まれます。 こんにちは,S.T.です。Amazon Aurora MySQLで少し気になる現象を見かけたので紹介します。この現象を知っていれば回避できるので,クリティカルな影響があるということではないですが,将来直ってくれると嬉しいですね。 1.Amazon Aurora MySQLとは Amazon Aurora MySQLはAWSで利用できるマネージドのRDBです。コ

                                                        Amazon Aurora MySQLでテーブル再構築を伴う操作をするとテーブルが見えなくなるっぽい - GMOインターネットグループ グループ研究開発本部(次世代システム研究室)
                                                      • Go言語で基本的なCRUD操作を行うREST APIを作成 | DevelopersIO

                                                        Javaのエンジニアだった私がGo言語でREST APIを作る上で学んだことをまとめています。 プロジェクト構成、単体テスト、Dockerイメージの作成など実際にREST APIを開発する上で必要だと思われる要素を盛り込みつつサンプルプロジェクトを作成していきます。 はじめに Javaのエンジニアだった私がGo言語でREST APIを作る上で学んだことをまとめています。 プロジェクト構成、単体テスト、Dockerイメージの作成など実際にREST APIを開発する上で必要だと思われる要素を盛り込みつつサンプルプロジェクトを作成していきます。 今回はできるだけ外部ライブラリやフレームワークを使わずにGo言語の標準機能のみで開発しました。 これからバックエンドにGo言語を使用することを検討されている方の参考になれば幸いです。 ※この記事は既にGo言語の開発環境をセットアップ済みで基本的な文法を学

                                                          Go言語で基本的なCRUD操作を行うREST APIを作成 | DevelopersIO
                                                        • MySQL 5.7 to 8 check list

                                                          mysql57to8.md 確認すること メンテナンス時間をどれくらい取れるかで戦略が決まる。 基本的にはメンテナンス時間を十分に取れたほうが良い。 またリスクをどれだけ許容できるかもビジネスによるので要確認しておくべき。 基本的には一度切り替えてしまうとロールバックすることは簡単ではない。 覚悟を決めて突き進む必要がある 最初に諦めること MyISAMを使いたい 8でも動くけど諦めろ、もう未来はない InnoDBのほうがDisk サイズを消費する、countが遅い、などの課題はあるので簡単ではないが… InnoDB memcached Pluginとか使ってるんだよね 諦めろ、未来はない これを機にアーキテクチャを見直しましょう PKが無いtableがあるんだよね すべてのtableにまずPKを付けるんだ このあと、DMSを使ったりとかなにをするにしても死ぬ そもそもデータモデルとして死

                                                            MySQL 5.7 to 8 check list
                                                          • MySQL8.0でSELECT COUNT(*)が低速になる動作は8.0.37で解消されていた! - CyberAgent SRG #ca_srg

                                                            メディア統括本部 サービスリライアビリティグループ(SRG)の鬼海雄太(@fat47)です。 #SRG(Service Reliability Group)は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 本記事は、MySQ

                                                              MySQL8.0でSELECT COUNT(*)が低速になる動作は8.0.37で解消されていた! - CyberAgent SRG #ca_srg
                                                            • 8年以上開発されているRailsプロダクトーーfreee会計をRails 6にするまで - freee Developers Hub

                                                              こんにちは、freee会計でエンジニアをしている @sakakibara-setu です。 普段は債権債務に関する機能を担当するチームに所属して開発を行っていますが、この度freee会計のRailsアップデートを担当することになりました。 実はfreee会計は、先日2021年12月にRails 5系からRails 6系へとメジャーアップデートされました。 ありがたいことにこのメジャーアップデートによる問題は一件も発生しなかったため、皆様には特にお変わりなくご利用いただけたかと思います。 その上で社内の開発環境においては様々な恩恵を得ることができたので、結果は成功と言っていいと思います。 しかしながら、その道のりはお世辞にもうまくいったことばかりではなく、反省すべきことも多々ありました。 アップデート作業には壁とも言えるような問題がいくつもありましたが、それはfreee会計が8年以上開発され

                                                                8年以上開発されているRailsプロダクトーーfreee会計をRails 6にするまで - freee Developers Hub
                                                              • EmbulkでPostgreSQLをMySQLに移行した話 - LIVESENSE ENGINEER BLOG

                                                                こんにちは。マッハバイトを運営するアルバイト事業部エンジニアの mnmandahalf です。 先日、マッハバイトの販売管理システムで使っているデータベースをオンプレPostgreSQLからAmazon Aurora MySQLに移行しました。 本記事では移行に至った背景、吸収する必要があった差分や苦労した点についてお話しします。 環境 移行前のバージョン: PostgreSQL 9.4 ※ドキュメントはバージョン14のものを添付しています 移行後のバージョン: Aurora MySQL 3.02.0 (compatible with MySQL 8.0.23) 環境 MySQL移行の背景 データ移行方法の検討 Embulkの実行で考慮したポイント Embulkの設定 scram-sha-256認証への対応 タイムスタンプが9時間巻き戻る FK制約を無効化できない PostgreSQLとM

                                                                  EmbulkでPostgreSQLをMySQLに移行した話 - LIVESENSE ENGINEER BLOG
                                                                • Aurora MySQLをMySQL8.0へ移行した話 - inSmartBank

                                                                  こんにちは!SREを担当してます上平と申します。 このエントリーではAurora MySQL5.7互換からMySQL8.0互換への移行を実施した際の流れや学びに関して紹介したいと思います! B/43 では Aurora MySQL5.7系をサービスリリースから使っており、Aurora MySQL バージョン2のサポート終了日(2024/10/31)が近づいているのもあったので、移行することにしました。 Amazon Aurora バージョン - Amazon Aurora これからAurora MySQL8.0へ移行を検討されている方の参考になれば幸いです。 想定される読者 Aurora MySQL 5.7系を使っていて、アップグレードを検討している方 実際の Aurora MySQL 8.0 への移行手順を知りたい方 AWS インフラに興味がある方 前提 Aurora MySQL5.7互

                                                                    Aurora MySQLをMySQL8.0へ移行した話 - inSmartBank
                                                                  • MySQL 8.1登場!!Innovation ReleaseとLTSについて

                                                                    MySQLの最新バージョンである「8.1」が発表されたので超久しぶりに筆を取った。しばらく筆を取らなかった理由は個人的なものなのだが、このブログはごく個人的な活動であるので諸々の事情はご容赦頂きたい。 さて、MySQL 8.0の次のバージョン番号は何になるかという憶測は色々あったと思うのだが、8.1というものに落ち着いた結果になった。(9.0にしてしまうと、2桁目の番号が意味をなさなくなってしまうからね!!ちなみに次のバージョンは8.2、8.3・・・という具合に続く予定だ。)8.1という番号はバグデータベース上で既にチラチラと出ていたので、公式な発表よりも前に気づいていた人も多かったのではないだろうか。本稿では、バージョン8.1の概要と、8.1リリースと同時に発表されたInnovation ReleaseおよびLTS(Long Time Support)について解説しようと思う。 Inno

                                                                      MySQL 8.1登場!!Innovation ReleaseとLTSについて
                                                                    • 大規模サービスのインフラを全面的にリプレイスした話 - Qiita

                                                                      はじめに こんにちは。雑食系エンジニアの勝又です。 今回は、私が2年ほど参画させていただいた大規模サービスのインフラやDevOps周りを全面的にリプレイスしたお話について簡単にご紹介させていただきます。(内容に関しては事前に参画先企業様に確認していただいております) サービス概要 詳細な内容は伏せますが、メインとなるテーブルのレコード数が数十億件、スパイク時には数万〜数十万のユーザーが一斉にアクセスする大規模サービスです。 技術的負債 長く運用されてきたサービスのあるあるですが、新機能の追加が最優先されてきたことにより、こちらのサービスにも下記のような技術的負債が大量に積み上がっていました。 RubyやRailsやMySQLのバージョンがかなり古い インフラの構成がコードではなくドキュメントで管理されている アプリケーションの構成管理がおこなわれていない CI/CDパイプラインが構築されて

                                                                        大規模サービスのインフラを全面的にリプレイスした話 - Qiita
                                                                      • Aurora MySQL 5.7とRailsで実現する全文検索機能 - dely Tech Blog

                                                                        こんにちは。 クラシル開発部、バックエンドエンジニアの松嶋です。 delyに入社してから約3年間、私はSREチームに所属していましたが、昨年10月にバックエンドに転向しました。バックエンドに転向してからは、主にクラシルアプリの公式レシピおよびCGMコンテンツの検索機能に関する開発・改善に取り組んでいます。 クラシルは、2016年2月にサービスを開始してから、管理栄養士監修の「誰でも安全に・おいしい料理を作ることができるレシピ動画」を5万件以上提供してきました。 昨年12月には、クラシルのブランドリニューアルを行い、今後はシェフや料理研究家を中心としたクリエイターとともに多様化したユーザーの食の好みや課題解決に応えられるよう、幅広い食のコンテンツを提供するプラットフォームを目指しています。 ブランドリニューアルの詳細に関しては、こちらを御覧ください。 www.kurashiru.com この

                                                                          Aurora MySQL 5.7とRailsで実現する全文検索機能 - dely Tech Blog
                                                                        • 最近のMySQL 8.0 の内部一時テーブルの改善について

                                                                          MySQL では sort_buffer_size 以上にソート領域が必要になった場合、もしくは一部の条件に当てはまるSQLについては、内部一時テーブルを作成し処理を行うという仕組みになっています。 8.4.4 MySQL での内部一時テーブルの使用 この内部一時テーブルの仕組みに MySQL 8.0 から TempTable ストレージエンジンを利用する事ができるようになりました。 TempTable ストレージエンジンの挙動については、過去の弊社ブログ記事で説明しています。 TempTable ストレージエンジンについて TempTable ストレージエンジンはMySQL 8.0で導入されたということもあり、初期パッチバージョンに比べて改善が行われています。 今回の記事では、TempTableストレージエンジンの最近追加された機能についてご紹介します。 基本的なソートバッファと内部一時

                                                                            最近のMySQL 8.0 の内部一時テーブルの改善について
                                                                          • 「Amazon Aurora Serverless V2」正式版に。瞬時にスケールして数十万トランザクションに対応、データベース容量も自動管理

                                                                            「Amazon Aurora Serverless V2」正式版に。瞬時にスケールして数十万トランザクションに対応、データベース容量も自動管理 Amazon Web Services(AWS)は、クラウド上でデータベースのマネージドサービスとして提供している「Amazon Aurora Serverless」の新バージョン「Amazon Aurora Serverless V2」の正式版としてのリリースを発表しました。 Instant scale ↔️ instant cost efficiency. Amazon Aurora Serverless v2 scales in a fraction of a second while eliminating database capacity management, so you only pay for what you use & sa

                                                                              「Amazon Aurora Serverless V2」正式版に。瞬時にスケールして数十万トランザクションに対応、データベース容量も自動管理
                                                                            • AWSマネージドサービス+Terraformを活用してDBオペレーションをより安全&簡単に(pt-oscの例) - freee Developers Hub

                                                                              おはこんばんちは、Database Reliability Engineerの橋本です。 以前、freee Developers Hubにて、MySQLのスキーマ変更をオンラインで実施するためのpt-online-schema-changeの導入に関する検討記事を書かせていただきました。こちらはカラムの型変更のようなテーブルロックがかかりオンラインで実施できないような変更や、オンラインで実施できても完了までに長時間かかるようなケースで用いています*1。 運用の都合上、pt-online-schema-changeをそのまま用いるのではなく、以下の4つのフェーズにそれぞれ作業を分割し、個別に実行できるようにしています。前回の記事を要約すると次の流れとなります: pt-online-schema-change コマンドを実行し、スキーマ変更済みテーブルを新規作成し、pt-online-sche

                                                                                AWSマネージドサービス+Terraformを活用してDBオペレーションをより安全&簡単に(pt-oscの例) - freee Developers Hub
                                                                              • 開発/Stg環境のための本番DBマスキングと継続的リストアの仕組みを作りました | ランサーズ(Lancers)エンジニアブログ

                                                                                SREチームの安達(@adachin0817)です。今回はMENTA、Lancers Creative、Lancers Agencyでマスキングした本番環境のデータをStgや開発環境のMySQLコンテナへ毎週リストアする仕組みを実装しました。実際にここらへんは運用をしていく中で一苦労されている方も多いのではないでしょうか。それではまず背景と、実装するに当たっての活動含めてご紹介できればと思います。 背景 今回はMENTAを例にしています。各サービスの開発環境はDockerを利用しており、本番とStg環境はTerraformで管理しています。カラム追加ではマイグレーションを実行することでサンプルのスキーマファイルを投入して開発をしているのですが、たまに開発環境で動いていたソースがStgや本番で動かないといったことで開発効率が下がることが見受けられます。開発メンバーにとってはより本番環境に近い

                                                                                  開発/Stg環境のための本番DBマスキングと継続的リストアの仕組みを作りました | ランサーズ(Lancers)エンジニアブログ
                                                                                • Aurora Serverless v2を本番導入した話 〜検討や導入時のポイント・得られた効果について〜 - ZOZO TECH BLOG

                                                                                  はじめに こんにちは。SRE部ECプラットフォーム基盤SREブロックの石田です。 本記事では、Aurora Serverless v2を本番導入するにあたってどのような検討をし、どのように導入していったか、また導入後に得られた効果について紹介します。 はじめに Aurora Serverless とは 背景 比較検討 比較内容 方針の決定 アーキテクチャ 導入 1. Aurora Serverless v2を手動で構築 2. AWS CloudFormationでProvisioned型Aurora MySQLバージョン3を再構築 3. AWS CloudFormationでAurora Serverless v2に移行 4. 負荷試験・障害試験 負荷試験 障害試験 導入により得られた効果 柔軟なスケーリング インフラコスト 最後に Aurora Serverless とは Aurora

                                                                                    Aurora Serverless v2を本番導入した話 〜検討や導入時のポイント・得られた効果について〜 - ZOZO TECH BLOG