In InnoDB Data Locking – Part 1 “Introduction” we’ve described the difficulties Lock System tries to solve using metaphor of people trying to concurrently edit spreadsheets. While it might be useful metaphor to get some intuitions about the problem, to talk about solutions it helps to know at least a little about the “reality” this metaphor maps to. In this post I’ll talk about how statements we’v
連載第55回でご紹介したMySQL InnoDB ReplicaSetは、従来型のレプリケーションの運用管理の効率を向上させることに主眼をおいて開発されているパッケージです。データの複製は非同期レプリケーションとなり、データベースの自動フェイルオーバー機能もないため、高可用性構成しては物足りない面もあります。 MySQL InnoDB Clusterで利用されているグループ・レプリケーションはコミットされたトランザクションが他のノードに複製されることが保証できるため、高可用性を求める場合にはより適切な選択肢となります。参照時のノード間のデータ整合性は設定により変更できます。ただし、グループ・レプリケーションの要件にはGTID（Global Transaction IDentifier）や行ベースのバイナリログが含まれているほか、制約事項のひとつとしては利用可能なストレージエンジンがInno
check-mysql の通信を暗号化できるオプションを追加しました ほか - Mackerel お知らせ #mackerelio
こんにちは。Mackerelチーム CRE の三浦（ id:missasan ）です。今回のアップデート内容をお知らせします。 check-mysql の通信を暗号化できるオプションを追加しました MySQLのバージョンによって取得できていなかったメトリックを取得できるように修正しました Amazon Aurora PostgreSQL互換インターフェースへの対応を行いました check-mysql の通信を暗号化できるオプションを追加しました go-check-plugins v0.40.0 にて check-mysql に以下3つのオプションを追加しました。 これらのオプションにより、プラグインとデータベース間の通信を暗号化することができます。 --tls Enable TLS connection --tls-root-cert The root certificate used f
ProxySQL を利用した Aurora MySQL の課題解決 [DeNA インフラ SRE] | BLOG - DeNA Engineering
2022.11.01 技術記事 ProxySQL を利用した Aurora MySQL の課題解決 [DeNA インフラ SRE] by yayohei #infrastructure #sre #database #aws #aurora #mysql #proxysql #stabilization #livestreaming-infrastructure #infra-quality こんにちは、 IT 本部 IT 基盤部第一グループの山本です。 今回は ProxySQL を利用した Aurora MySQL の新規接続の遅延問題の解消方法について紹介したいと思います。 Aurora MySQL のメリット Aurora MySQL のメリットとしては本稿で詳しく語るまでもないですが、Writer の 自動 Failover、Snapshot の取得の容易さ、Storage 故障の
![ProxySQL を利用した Aurora MySQL の課題解決 [DeNA インフラ SRE] | BLOG - DeNA Engineering](https://cdn-ak-scissors.b.st-hatena.com/image/square/86065d7b8409d04e7be80a93878f716de9247a45/height=288;version=1;width=512/https%3A%2F%2Fengineering.dena.com%2Fblog%2F2022%2F11%2Finfra-proxysql%2Fcover.png)
スタートアップが取組むコンテナ化。EC2からECS Fargate移行の道のり - カミナシ エンジニアブログ
初めまして。株式会社カミナシPMの@gtongy1です。 みなさんは、インフラのコンテナ化はお済みでしょうか？ 弊社は今年6月頃にサービスを正式にリリースしたのですが、それ以前はEC2 + ELBでインフラを構築しており、それまでになかなかコンテナ化をしたくても出来ない状態でした。 各社様々な背景はあると思いますが、自分は コンテナ化をすればいいのは、なんとなくわかる。ただ、どこから始めたらいいんだろうか EC2構成でも動いているがために、なかなか変えようとする一歩目が踏み出せない コンテナ化を本番環境で構築した経験がない。実際にどんなことが課題として上がるんだろうか あたりに不安を感じていました。 ただ、インフラ運用に事業の足を取られてしまうリスクを抱える、それが嫌でコンテナ化を今回行いました。 そんな中での取り組みや課題感を先日話してきたので、その詳細をお伝え出来ればなと思います。 発
曖昧に理解してるかもと思い、自分の振り返りのために書いてます。 先日書いた記事で作ったデータで説明します。 MySQLのロック 通常、DML実行時に取得されるロックは排他ロックと共有ロックで構成されます。 最初にトランザクションでロックをかけたほうが排他ロック、 ロックがかかったデータを参照だけするためにかけたほうが共有ロックと呼ばれます。 共有ロックがかかった状態では他のトランザクションでも共有ロックはかかり（データの読み取りができ）ますが、データの書き込みはできません。 一方、他のトランザクションが同じ行をロックするのを回避するタイプのロックを排他ロックといいます。 トランザクション分離レベルに応じて、 他のトランザクションが同じ行に書き込むのをブロックできる 他のトランザクションが同じ行を読み取るのをブロックできる となります。 MySQLで書き込み中データ読み取れると思ったでしょ？
OBCIセミナー（特徴あるDBエンジンを取り上げる予定） MySQL関連（日本オラクル MySQL GBU担当） PostgreSQL関連（SRA OSS Inc. 担当） パネルディスカッション「多様性時代のDB選択」 ［MySQL］2020年7月の主な出来事 2020年7月にはMySQLサーバー8.0.21、5.7.31、5.6.49の各マイナーバージョンをはじめ、商用版およびコミュニティ版のほぼ全ての製品のマイナーバージョンアップが行われました。 MySQL 8.0.21の新機能 MySQL 8.0.21の主な新機能は下記の通りです。MySQLサーバー開発チームのブログでもMySQL 8.0.21の新機能の紹介がされています。 InnoDBストレージエンジンのトランザクションログ無効化 大量データのロード時やレプリケーションのレプリカの初回データロードなどに、一時的にトランザクション
こんにちわ。せじまです。珍しく replication の話をします。しかも、複数回に渡って続きます。連載です。 はじめに 先日、 こちらのスライドで 「詳しくは後日、ソースコード交えつつ別のかたちでご紹介したいと思います。」と言っていた件です。 Row-Based Replication の話をします。 昨年の8月頃、「そろそろ、SBRからRBRに移行して良い時期かなぁ、しないと将来めんどくさいかなぁ」「でも、 SET GLOBAL で binlog_format 変更できないと、手間かかってしょうがないなぁ」「じゃソースコード読むかぁ」ということで、MySQL の Replication はそんなに得意分野でもないので、他の仕事の合間にちょくちょく調べて、社内文書にまとめてました。 公開しても良いのでは、と思った内容なので、一部修正しつつ、お届けします。 はじめに断っておきますと、この
MySQLのALTER TABLEでTEXT NOT NULLなカラムをエラー無しで追加する - $shibayu36->blog;
課題 MySQL :: MySQL 5.6 リファレンスマニュアル :: 11.6 データ型デフォルト値によると、 MySQLのTEXTカラムにはデフォルト値を設定できない 厳密な SQL モードを有効にした場合、NOT NULLなカラムがINSERTに含まれていないとエラーが発生する そのため、以下のようなスキーマが存在していて CREATE TABLE `article` ( `id` BIGINT UNSIGNED NOT NULL, `title` VARCHAR(100) NOT NULL, ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; アプリケーションから次のようにINSERT文を発行しているとして INSERT INTO `article` SET id = :id, title = :title 先にALTER TABLE article
InnoDBをチューニングする際に、真っ先に確認するものといえばInnoDBバッファプールがあります。これは頻繁にアクセスされたテーブルデータやインデックスデータをキャッシュし、リクエストを高速に処理するための重要な機構です。基本的にはバッファプールは大きな値を設定するようにガイドされています。データサイズがすべてバッファプールサイズに収まるように設定すると安定したサービスの提供が可能です。 バッファプールサイズよりもデータサイズが大きい場合は、ディスクへのアクセスが頻発して運用しているサービスに影響があることもあります。しかし、サービスが頻繁にアクセスするデータは決まっていて（過去のデータにはほとんどアクセスしない）、そのデータがすべてバッファプール上にあるために問題なくサービスを運用できることもあります。このように、サービスの特性によるワーキングセットが重要になります。 今回は、バ
D. M. です。今回は新人研修で扱う DB のパフォーマンスチューニングについてのお話です。 この記事を書こうと思ったキッカケ 私はここ数年新人やインターンの学生のメンターをよく担当しているのですが、学生と会社員エンジニアの間にはデータベース（ RDB ）の知見に大きな溝があると感じています。 研修で「とりあえずサービスを作ってみよう！」という課題を出すと、最近の新卒の方は平均的なレベルが高く、いいアイディアでさらっと Web サイトを立ち上げることができます。 ただそのサイトが毎日 100 万人が使うことを想定して充分なチューニングができる人は新人段階ではほんのわずかです。毎回同じようなことを指摘するのですが、特に多いのが DB 関連です。多くの方が DB の経験がほとんどなくあまり扱えないのです。コンピュータサイエンス専攻出身の方はプログラミングスキルをはじめとした技術的な知見を持っ
KVSあるいはKVSベースのNewSQLに高速なAuto Incrementを実装する | CyberAgent Developers Blog
AI事業本部の黒崎( @kuro_m88 )です。 MySQL、PostgreSQLのようなRDBとAmazon DynamoDBやCloud SpannerのようなNoSQL、NewSQL系のDBを比較したときに、後者はRDBのauto incrementのような機能を実装しようとすると前者と比較して性能が出ない問題があります。この問題に対してRedisのLua Scriptingを用いて採番用のキャッシュを実装し、併用することで高速化した事例を紹介します。 本記事ではAmazon DynamoDBやCloud Spannerが採用されている環境を想定します。特に特定のDBに依存した考え方ではないので、その他のKVSやKVSベースのNewSQLにも応用できる考え方かと思います。手法を検討するのに使ったコードはGoで実装しました。 前提 前提としてKVSのような分散DBにおいて、auto
MySQL 8.0.22 で innodb_log_writer_threads の効果を見てみる - Qiita
これは MySQL Advent Calendar 2020 23 日目のエントリです。 昨日は atsuizo さんの「MySQLのデータ投入順序とデータファイルサイズのお話」でした。 そして、↓の記事の続きでもあります。 MySQL を使って EC2 r6g.large vs r5.large（mysqlslap 対決）をやってみた 前回は MySQL Community Server をインストールした AWS の EC2 インスタンスを使い、Graviton2 プロセッサと Intel プロセッサで mysqlslap 対決をしてみましたが、その延長で、innodb_log_writer_threadsの効果を確かめてみました。 innodb_log_writer_threadsとは MySQL 8.0.22 で追加された InnoDB の設定項目（パラメータ）です。 innodb
This blog is in reference to our previous ones for ‘Innodb Performance Optimizations Basics’ 2007 and 2013. Although there have been many blogs about adjusting MySQL variables for better performance since then, I think this topic deserves a blog update since the last update was a decade ago, and MySQL 5.7 and 8.0 have been released since then with some major changes. These guidelines work well for
MySQLのInnoDBとMyISAMのパフォーマンス比較をしてみましたー 対象のMySQLのバージョンは5.7と8.0です。 結論としては、 INSERTはMyISAMの方が早い SELECT・UPDATE・DELETEは 8.0ではInnoDBの方が早い 5.7ではSELECT・DELETEはMyISAMの方が早い。UPDATEはInnoDBの方が早い という結果でしたー！ なお、MySQLのバージョンごとのサポート期限は以下のようになっています。 MySQLバージョン MySQL AWS RDSのMySQL AWS AuroraのMySQL 5.7 2023年10月31日 2023 年 10 月 2024 年 10 月 31 日 (Aurora バージョン2) 8.0 2026年4月30日 未定 未定 (Aurora バージョン3) 検証条件 MySQL5.7-MyISAMで、1万件
使用されず役に立たないインデックスを定義するのは、SQLアンチパターンの1つ「インデックスショットガン」として知られています。使用されていないインデックスを定義するのは、ディスク容量を圧迫して、さらに更新コストも掛かるという良いこと無しな状態です。 ただ実際には、あなたが使用されていないインデックスを見つけたとしても、安易にドロップするのは非常に危険です。ドロップするのは時間がかかりませんが、インデックスを再構築するまでには時間がかかります。 もしも万が一そのインデックスが使用されているクエリが存在するとしたら、その時点から障害につながってしまう可能性があります。ドロップはしたくないけど、使わないようにして影響を確認したい……、今回はそんな時に便利なMySQL 8.0の新機能「Invisible Indexes」を使ってインデックスを外した時の影響を調べてみましょう。 検証環境 今回はDo
週刊Railsウォッチ（20200601前編）Active Recordに新機能「delegated typing」追加、RuboCopのデフォルト設定アンケートほか｜TechRacho by BPS株式会社
2020.06.01 週刊Railsウォッチ（20200601前編）Active Recordに新機能「delegated typing」追加、RuboCopのデフォルト設定アンケートほか こんにちは、hachi8833です。この記事↓にどよめきました👍🎉😂。 ⚓オープニングつっつき: 経産省のnpmモジュールが素晴らしい 元記事: 経産省発の npm モジュール！住所や電話番号の正規化、ジオコーディングなどができる IMI コンポーネントツールを試した！ - Geolonia developer's blog サイト: IMI 情報共有基盤 コンポーネントツール 経産省が住所変換や法人種別名、電話番号の正規化に使えるIMIコンポーネントツールを公開しました。 ソースコードも公開。README にも使い方が丁寧に書かれていました。https://t.co/fPbV00EgZP 素晴ら
PostgreSQL と MySQL の決定的な違い
基本： PostgreSQL と MySQL の概要 PostgreSQLとMySQLの基本的な概要と歴史から始めましょう。すでに基本的なことを知っている場合は、このセクションは飛ばしてください。初心者の方はこのセクションをお読みください。 MySQL とは MySQLは、世界で最も一般的に使用されているリレーショナルデータベース管理システム（RDBMS）です。2023年に開発者の間で2番目に高い使用率を誇るこのオープンソース RDBMS は、高速で信頼性が高く、安定したセキュアでスケーラブルなデータ管理を組織に提供することで知られています。 MySQLは、スケーラブルな Web アプリケーションに最適な選択肢です。MySQLはLAMPスタックに標準搭載されています。LAMPスタックはウェブ開発で非常に人気があります。これは、Linux、Apache HTTP Server、MySQL、P
MySQLでは実行計画を生成するために、コストモデルを採用しています。オプティマイザーは実行計画を生成するために、さまざまなオペレーションからコストを見積もります。その際にベースとなる推定値が、mysqlデータベースのserver_costとengine_costテーブルに格納されていています。MySQL 5.6とそれ以前はコストパラメータの値は定数としてハードコードされていましたが、MySQL 5.7とそれ以降からはコストパラメータの値を変更することが可能になりました。 今回はMySQL 8.0.17を使用して、コスト見積もりを調整する方法について紹介したいと思います。 server_costテーブル server_costは、一般的なサーバー操作のオプティマイザーの見積もりが格納されているテーブルです。SELECTしてみると、以下のようになっています。 mysql >SELECT *
MySQL Shell's dump loading utility util.loadDump(), introduced in MySQL Shell 8.0.21, supports the import into a MySQL HeatWave Service DB System (a MySQL DB System, for short) or a MySQL Server instance of schemas or tables dumped using MySQL Shell's Section 11.5, “Instance Dump Utility, Schema Dump Utility, and Table Dump Utility”. The dump loading utility provides data streaming from remote sto
はてなブログ独自の集計による人気記事のランキング。4月18日（日）から4月24日（土）〔2021年4月第4週〕のトップ30です*1。 # タイトル／著者とブックマーク 1 「愛のあるセックス」はなぜ必要か（読書メモ：『性と愛の脳科学』） - 道徳的動物日記 by id:DavitRice 2 日本のソフトウェア開発はなぜ世界から落伍したのか。中国人エンジニアの見方 - 中華IT最新事情 by id:tamakino 3 ティム・オライリーが「シリコンバレーの終焉」について長文を書いていたのでまとめておく - YAMDAS現更新履歴 by id:yomoyomo 4 国内約200組織へ行われたサイバー攻撃と関係者の書類送検についてまとめてみた - piyolog by id:piyokango 5 テイエムオペラオーのオペラトークを解析する - ウマ娘考察 - 世界観警察 by id:syl
エンティティの識別子に ULID を使ってみよう
エンティティの識別子の生成タイミング問題 DDD[1]では，一意な識別子を持ち，その識別子によって識別できるモデルをエンティティ (Entity) として表現します．このエンティティの識別子の生成方法には様々な種類がありますが，大きく分けて永続化前に生成する早期生成と永続化後に生成する遅延生成の2種類に分けられます． エンティティの識別子の生成に遅延生成を用いると本来 Not Null な識別子を Nullbale として扱う必要性が生じてしまいます．これを避けるのであれば，早期生成を採用すると良く，IDDD本[2]などではUUIDやGUIDをアプリケーション側で生成し識別子に用いる例が紹介されています． しかし，技術的な問題でUUIDなどのランダムな値を識別子として採用しづらいケースも存在します．たとえば，MySQL (InnoDB) ではプライマリキーにランダムな値を用いるとINSER
Go2 Advent Calendar 2019 の 6 日目の記事です。 Go の database/sql って使いにくくないでしょうか。 二年ちょっと前にもっと楽にできないかなと思って調べました。 欲しかったもの database/sql を使いやすくしたもの ORM は要らない ただし、SELECT と INSERT は楽をしたい ORM を必須とする人もいると思いますが、そのときは直に SQL 文を書きたかったので、それに合ったライブラリだけを試しました。 試したライブラリ sqlx Connect()、MustExec() など database/sql とのメソッド名の違いが大きくて、感覚的に避けてしまいました。 gorp 割と近い感じで使えて好感触でした。 というわけで gorp を選び、そのときに書いた記事が下記二つです。 【Go】gorp を使って DB 操作を少し楽に
[アップデート] インターネットトラフィックのパフォーマンスが最大60%向上！Amazon S3 マルチリージョンアクセスポイントの紹介 | DevelopersIO
[アップデート] インターネットトラフィックのパフォーマンスが最大60%向上！Amazon S3 マルチリージョンアクセスポイントの紹介 アップデートからしばらく時間が経ってしまいましたが、先日リリースされた Amazon S3 Multi-Region Access Point についてご紹介します。 Amazon S3 Multi-Region Access Point が、レプリケートされたデータセットへのアクセスを最大 60% 加速 S3 Multi-Region Access Point グローバル展開されるアプリケーションやリージョン障害を考慮したアーキテクチャを設計する際に、S3 のクロスリージョンレプリケーション(CRR)は広く採用されている方法です。 しかしながら CRR で複数リージョンのバケットにオブジェクトを配置できたとしても、最短のレイテンシでアクセスするためにど
![[アップデート] インターネットトラフィックのパフォーマンスが最大60%向上！Amazon S3 マルチリージョンアクセスポイントの紹介 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/55e5ee85a70b0b6893eeca79750f0d06a94b8595/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Famazon-s3.png)
Amazon Aurora のローカルストレージについて調べてみた - Link and Motivation Developers' Blog
こんにちは。リンクアンドモチベーション SRE グループの綿引と申します。 今回 Amazon Aurora の「ローカルストレージ」に関して調べる機会がありましたのでご紹介したいと思います。 背景 先日CloudWatchメトリクスを眺めていたのですが、RDSに「FreeLocalStorage」という項目があることに気づきました。 「Aurora のボリュームは自動拡張するのにストレージのメトリクスってあるんだ」と驚き、次に「このLocalStorageとは何だっけ？」ということが気になり、調べてみたということが背景になります。 Amazon Aurora とは まず簡単に Aurora についておさらいですが、フルマネージド型のリレーショナルデータベースサービスで以下のような特徴があります。 （参考：「Amazon Aurora の特徴」） ----------------- MyS
こんにちわ。せじまです。 2021-07-09、日本MySQLユーザ会会(MyNA会) 2021年07月 -下位レイヤ勉強会- でお話させていただくことになりました。勉強会等でお話させていただくのはずいぶん久しぶりで、オンラインイベントでは初となります。 資料を読み返してると「興味のある方は、予め、関心のある補足資料等にざっと目を通しておいていただいた方が、よりわかりやすくなるかも」と感じたので、イベント開催一週間前ですが、事前に資料を公開させていただくことにしました。
こんにちは。 開発チームのフリー素材担当、まんだいです。 かなり出遅れてますが mysqldump の後継ツールとなる mysqlpump を使ってみたので、まだ使ったことがない人向けにオススメポイントをまとめてみました。 さすが後継というべきか、基本的なオプションの使い方はそのままで mysqldump から移行してきた人にも優しい設計になっていましたので、ぜひ使ってみてほしいと思いました。 MySQL に同梱されているのがポイント高いですよね。 これだけでも乗り換える価値がある、進捗表示 今回試したデータベースはせいぜい 200MB 程度のものなのであまり恩恵はなかったですが、 mysqlpump はダンプの進行具合を逐一表示してくれます。 mysqlpump -uroot -p --databases xxxxx > xxxxx_20XX0X0X.sql Enter password
ISUCON13にチーム「ウー馬場ーイー222」で参加して最終スコアは 49,344 でした - Gマイナー志向
TL;DR 2023年11月25日に開催されたISUCON13に参加しました。最終スコアは49,344でした。実装言語はGoです。今回のチーム名の由来は申し込み時のチームIDが222だったためです。 追記：30位でギリギリTOP30チームに入りました。やったね。 今回スコアが思ったほど奮わなかったのですが、敗因はN+1を甘く見ていたことだと思っています。MySQLのスロークエリーログ（トータル実行時間順）を見ているだけではだめで、実行回数をもっと重視する必要があるなと思いました。うん、そうだね。 今回はDNSが課題に組み込まれており、インフラエンジニア3人態勢の我々のチームの得意分野とする領域のはずだったのですが、DBのボトルネックを解消できずDNS周りに着手できませんでした。くやしー。 運営の皆様、ことしもよい問題をありがとうございました。来年こそはリベンジして上位入賞を目指したいと思い
S3へ出力したCloudWatch LogsのデータをS3 SelectとAthenaで確認してみた | DevelopersIO
Kinesis Data Firehose介し、S3へ出力したCloudWatch LogsのデータをS3 SelectとAthenaで確認してみました。 Kinesis Data Firehoseを使いCloudWatch LogのデータをS3に出力することが可能です。S3をデータソースにしたデータの確認方法は多々あると思いますが、ここではS3 SelectとAthenaを利用しログデータを確認してみたいと思います。本エントリでは、環境構築については割愛していますので、構築については以下ブログを参考にしてください。 CloudWatch LogsのログデータをKinesis Data Firehose経由でS3に出力する なお、ここではS3へ出力されたログデータはAurora監査ログを利用しています。 S3 Select 構成 Kinesis Data Firehose設定 配信ストリー
$ mysql Can't create a new thread (errno 11); if you are not out of available memory, you can consult the manual for a possible OS-dependent bug 上記のエラーが発生して MySQL に接続できなくなった場合、MySQL がメモリ不足となっている可能性があります。 メモリ使用量の計算 MySQL のメモリ使用量は、以下のような計算式で調べることができます。 このメモリ使用量が物理メモリサイズを超えると、メモリ不足が発生する可能性が高まるので、 物理メモリサイズを超えないように、バッファサイズとコネクション数を調整します。 グローバルバッファの設定 MySQL のバッファには、グローバルとスレッドの2種類があります。 グローバルバッファは MySQL
7/13 に MySQL 8.0.21 がリリースされました。 リリースノートを読んでいて「Functionality Added or Changed」の3つ目に InnoDB: Redo logging can now be enabled and disabled using ALTER INSTANCE {ENABLE|DISABLE} INNODB REDO_LOG syntax. This functionality is intended for loading data into a new MySQL instance. Disabling redo logging helps speed up data loading by avoiding redo log writes. The new INNODB_REDO_LOG_ENABLE privilege permit
この記事は「MySQL Advent Calendar 2019 21日目」です。 これまた大遅刻となってしまって申し訳ございませんでした;(´◦ω◦｀): これも言い訳はダメだぞ自分！ さて、今年中にどうしても書き残して置きたかった内容があったのですが、ありがたくも「Adovent Calenderに書いていいよ！」というお話しをいただいたので…書かせていただきます。 題して「MySQL InnoDB Cluster 反省会」。 何もMySQLを知らない人間が、いきなり MySQL InnoDB Cluster Group Replication を導入した、そんなお話です。 前提 InnoDB Clusterを採用した理由 採用する前にやったこと 反省会（マネジメントチックな話） MySQLはコミュニティのものである 複数バージョン間レプリケーションがサポートポリシー変更 反省会（技術
How can I troubleshoot low freeable memory in an Amazon RDS for MySQL database? I run an Amazon Relational Database Service (Amazon RDS) for MySQL instance. I see that my available memory is low, my database is out of memory, or low memory is causing latency issues in my application. I want to identify the source of the memory utilization and troubleshoot. Short description In Amazon RDS for MySQL
機械学習システムアーキテクチャ入門 #1
機械学習システムのアーキテクチャを検討する上で考慮すべき課題について調査しまとめた資料です。Money Forward 社内で開かれた MLOps についての勉強会のために作成しました。 ## Reference ### 大規模なデータを扱う難しさ - Architecture Evolution in Repro https://speakerdeck.com/joker1007/architecture-evolution-in-repro - Sidekiq to Kafka ストリームベースのmicro services https://speakerdeck.com/joker1007/sidekiq-to-kafka-sutorimubesufalsemicro-services - ReproのImport/Exportを支えるサーバーレスアーキテクチャhttps://spe
AWS re:Invent 2022 にて RDS の Blue/Green が発表されたことを受けて、この辺の具体的な運用をどのように改善できるのか考えていきます。 たいした内容ではないですが、丁寧に最適化して慣れれば、それなりに強い効果を発揮できそうな感じはあります。 ALTER TABLE の辛み まず復習からですが、RDS に Blue/Green が実装されるほど辛い運用はなんだったかというと、重い ALTER TABLE にあります。 ALTER には色々あるのでアレですが大雑把に言うと、容量や行数が大きいテーブルに対して実行すると、数時間単位～の処理時間がかかることが多く、しかもパッと見で進捗を把握できないという問題を抱えていました。それに対して色んな対策を取っていたと思います。例えば…… Handler_write SHOW GLOBAL STATUS LIKE ‘Hand
これは インフラ勉強会 Advent Calendar 2018 19 日目の記事です。 書いているうちに日付が変わってしまいました。 同カレンダーの 17 日目に、 「MySQL8.0 で起こる謎のデッドロックの条件を調べてみた」を data_locks・data_lock_waits テーブルで確かめてみた という記事を書きましたが、そもそも MySQL（InnoDB）のロックについて何も解説していないので、おそらく MySQL 初心者には全く意味の分からない記事になってしまったと思います（すみません）。 というわけで、すでに語りつくされている内容ですが、先の記事を理解するのに最低限必要になりそうなことを補足していきます。 ※MySQL に慣れている人にはいまさら解説不要な内容です。 MySQL（InnoDB）とトランザクション分離レベル 細かいことは説明しませんが、MySQL を含む
あけましておめでとうございます。 2022 年は、生活全般と専門的なソフトウェアエンジニアリングを分けて、振り返りをまとめました。 この記事は生活全般についてです。 私生活 体調管理 風邪症状は何度かありましたが、仕事に支障が出るほどではありませんでした。 どちらかというと、予防接種や自宅待機、保育園休園によってリズムが崩れることが多い一年でしたね。 子どもの予防接種全三回が 2023 年の 4 月までに終わるので、それで多少は落ち着いてくれるのを祈る日々です。 コミケ 2022 年は夏コミ（C100, 8/14）と冬コミ（C101, 12/31）の二回手伝いに行きました。人も徐々に戻ってきているような気がして、C99 ほど寂しい感じではなかったです。 冬コミは二スペだったのでスペースが広く使えて、いつもより余裕を持って望めました。毎回こうだと長時間緊張を強いられなくて済みます。 設営をは
オラクル、インメモリDBのMySQL HeatWaveに機械学習機能を追加。SQL文だけで学習、推論、説明の取得を実現
オラクル、インメモリDBのMySQL HeatWaveに機械学習機能を追加。SQL文だけで学習、推論、説明の取得を実現 オラクルは、MySQLにインメモリデータベースエンジンを搭載することで高速なOLAP機能を提供する「MySQL HeatWave」の新機能として、機械学習機能を提供する「MySQL HeatWave ML」を発表しました。 同時に、無停止でのHeatWaveのノード拡張と、ノードあたりのデータ格納量の倍増も発表されました。 [プレスリリース抄訳] オラクル、MySQL HeatWave MLを発表 - 開発者が簡単、迅速、経済的に利用可能なMySQL アプリケーション向けの強力な機械学習機能を提供 - Oracle Cloud Infrastructure（OCI）の東京と大阪を含む37のリージョンでご利用可能です https://t.co/ly7qGP8CZ5 #mys
技育祭は「技術者を育てる」ことを目的としたエンジニアを目指す学生のための日本最大のオンラインカンファレンスです。ここで登壇したのは、元2ちゃんねる管理人のひろゆき氏。エンジニアを目指す学生からの質問に答えました。全3回。2回目は、ひろゆき氏が思う「2チャンネル」がブレイクスルーした理由と、サービスを運営するうえで気をつけていたことについて。前回はこちら。 ノーコードが普及してもノーコードエンジニアとはならない 楓博光（以下、楓）：ありがとうございます。それでは、先ほどから何個かチャットで質問をいただいているので、それを拾いたいと思います。「なぜノーコードは日本で普及しないのでしょうか。私はノーコードエンジニアというポジションが将来できると思うのですが、ひろゆきさんはどうお考えでしょうか？」 ひろゆき氏（以下、ひろゆき）：コメントで「ノーコードエンジニア何？」と書いてありますが、それをエンジ
Mercari Advent Calendar 2017 の18日目です。 こんにちは。メルカリJPのサーバーサイドエンジニアの@Hirakuです。最近はメルカリNOWの立ち上げに関わっておりGoとPHPを行ったり来たりしています。 今回はネタとしては地味ですが、2017年に遭遇した、MySQLのデッドロックの話をしようと思います。 これまでも何度か話されている通り、メルカリのコア部分は今でもPHP + MySQLで構成されており、複雑なトランザクションを含む処理が各所に存在しています。そのため、意図せずしてデッドロックを作ってしまうことがあり、場合によっては重大な問題につながります。 今年は本当にデッドロックに関するトラブルに多く遭遇し、すっかり「デッドロック絶対に許さないおじさん」みたいになっていました。 事例1)出品者と購入者 デッドロックと言われてもピンと来ない方もいらっしゃるでし
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL :: InnoDB Data Locking - Part 2 "Locks"
第56回 MySQLの高可用性構成案、PostgreSQLのかなり気の早い新バージョン情報 | gihyo.jp
MySQLのギャップロックとネクストキーロック - 41から始めました
第60回 ついに連載が満5歳！ MySQL 8.0.21リリース、次バージョンPostgreSQL 13情報が続々 | gihyo.jp
チョットワカル Row-Based Replication・その１ | GREE Engineering
第101回 InnoDBバッファプールの状態を確認するさまざまな方法 | gihyo.jp
新人研修でマスターするDBのパフォーマンスチューニング - GMOインターネットグループ グループ研究開発本部
InnoDB Performance Optimization Basics
MySQLのInnoDBとMyISAMのパフォーマンス比較をしてみました
第110回 Invisible Indexesを使って気軽にチューニングを始めてみる | gihyo.jp
第108回 MySQLのコスト見積もりを調整する | gihyo.jp
MySQL :: MySQL Shell 8.0 :: 11.6 Dump Loading Utility
今週のはてなブログランキング〔2021年4月第4週〕 - 週刊はてなブログ
こんなデータベース用ライブラリを誰か作ってほしい（Go） - のんびり精進
NAND Flash から InnoDB にかけての話（仮） | GREE Engineering
ダンプが楽しくなる mysqldump の後継ツール mysqlpump の話 | 株式会社ビヨンド
MySQL でメモリ不足が発生したときのパラメータチューニング - Qiita
MySQL8.0.21の「Redoログ無効化」で大量書込処理を加速する - なからなLife
MySQL InnoDB Cluster 反省会 - ASMのきもち
Troubleshoot low freeable memory in Amazon RDS for MySQL
AWS RDS/AuroraのDDL運用を最適化する | 外道父の匠
MySQL のロックについて補足（注：すでに語りつくされている内容です） - Qiita
2022 年振り返り - yoheimuta’s blog
「“2ちゃんねる”は事業アイデアよりも設計の部分で流行った」 元管理人が語る、落ちない掲示板を支えた構造設計
デッドロックおじさん戦記 | メルカリエンジニアリング