※ このエントリは、はてなグループ終了に伴う、サブブログからの引越エントリ(2011/02)です。 ※ 情報が古い可能性もありますので、ご留意ください。 設定値 ログバッファ→ログファイル ディスクフラッシュ ====================================================================== 0 毎秒 毎秒 1 (初期値) COMMIT時 COMMIT時 2 COMMIT時 毎秒 innodb_flush_log_at_trx_commit が0に設定された時は、ログ バッファは1秒に一回ログ ファイルに書き込まれ、ディスク操作へのフラッシュはログ ファイル上で行われますが、トランザクション コミットの際には何も行われません。この値が1(デフォルト)の時は、ログ ファイルは各トランザクション コミットの時にログ ファイルに書き込まれ
はじめに タイトル通り、MySQL5.x系だとデッドロックになるんだけど、 MySQL8.0だとロック機構が変わってデッドロックにならないよ という組み合わせのお話。 僕はこの話をどっかで見た記憶が無かった（忘れた？）ので 教えてもらったとき結構驚いたんだけど、GA（8.0.11）では 既にこれがあったんで、まあ古い話なんだと思うし、 何をイマサラなのかもしれないので、ご存じの方は笑ってやってください。 ちなみに、REPEATABLE READでのお話なので、 READ COMMITTEDの場合は5系でもデッドロックにはなりまへん。 検証 今回やるのはこういうこと 最初のトランザクション（以下Tx1）でトランザクション開始、共有（S）ロックで全レコードを参照。 別のトランザクション（以下Tx2）でトランザクション開始、INSERTによる排他（X）ロック Tx1でINSERTによる排他（X）
Amazon Aurora のストレージに関連するメトリクスを理解する - サーバーワークスエンジニアブログ
CI部 佐竹です。 本日は Aurora のストレージについて、特に運用目線で知っておく必要がある CloudWatch メトリクスを解説します。 はじめに Aurora のストレージの種類について ローカルストレージ クラスターボリューム CloudWatch メトリクス FreeLocalStorage VolumeBytesUsed AuroraVolumeBytesLeftTotal まとめ はじめに Amazon RDS、Amazon Aurora におけるコンピュートリソースの利用状況は、特に何も設定をしなくとも CloudWatch に連携されており、メトリクスとして表示が可能です。例えば CPUUtilization などもその1つです。 今回は、その中でも特に運用上確認しておくことが重要なストレージに関するメトリクスについて解説を行います。 Aurora のストレージの種
MySQL 8.0 におけるJSON型のpartial update、およびそれに対するInnoDBの最適化について | GREE Engineering
HOMEInfoMySQL 8.0 におけるJSON型のpartial update、およびそれに対するInnoDBの最適化について こんにちわ。せじまです。 InnoDB に関する話をします。今回は大半が MySQL Server Blog や WorkLog のまとめ記事ですので、ゆるふわと言っていいでしょう。 JSON型の partial update に対する最適化というと、 binlog や replication にも関連するのですが、それについては今回は触れません。 はじめに 今回の内容は、MySQL Server Blog を熟読されている方であれば、すでにご存知のことが多いでしょう。ただ、「結局のところ、JSON型の partial update は、 InnoDB Adaptive Flushing においても有効なのか？」というところが疑問に残った方もいらっしゃるかも
MySQL :: MySQL 8.0 Reference Manual :: 17.12.1 Online DDL Operations
Enabling Automatic Configuration for a Dedicated MySQL Server
とても良い本だった。 MySQL の初級・上級の本は既刊であるが、その間を埋めるものがないので書かれたというもので、難易度を 1 ~ 5 で表すと 4 くらい、難易度 5 は 実践ハイパフォーマンスMySQL とのことだった。 あくまで深堀りしたいアプリケーションエンジニア向けの本で、DBA 向けではないと明記されていた。実際 MySQL (InnoDB) の実装詳細の説明が適度に打ち切られていて、ただし必要十分なトピックはカバーされていて、学習効率が良い。 筆者は Hack MySQL を運営していたり、過去に Percona で数々のツールを作ってきた実績 もあり、信頼が置ける。 1. Query Response Time まず North Star Metrics としてクエリのレスポンスタイムを定義し、その改善に必要な項目を体系立てて説明している。この構成がかなり良くて、明確な指
思い出せるうちに思い出せる範囲で… 例によって世に出る頃には全く違うことに取り組んでいるので、忙しくしてると何も書かずに終わってしまうのですが、こんなご時世、年末年始休暇があっても何も用事がなく折角なのですこし書き残します。本来は本家開発者のブログで英語で書くべきなんですが、込み入った話を英語で書く労力をかけるくらいなら次の問題解決にかけたほうがいいので、とりあえず日本語で書き残します… 私がMySQL界を離れている間にリリースされた8.0になってlog_sysのデザインが新しくなり、スケールが良くなったのですが、既存のハードを利用する大半のユーザーには、未だ荒かった実装のせいでデメリットの方が大きかったと思います。2019末くらいには悪い挙動と原因はある程度分かっていましたが、修正リリースは2020後半になってしまいました。 既存のスペックのハードウェアと、CPUコア多数搭載の最新ハード
今回はMySQLを利用するうえで、知っていると便利になるかもしれないちょっとした小技をいくつか紹介しようと思います。なお、利用するMySQLのバージョンは8.0.18、OSはCentOS 7を利用しています。 STRAIGHT_JOINの位置 第97回 JOIN_ORDERを使ってJOINの順番を決めるにて、バージョン8.0以降ではJOIN_ORDERヒント句を用いてJOINの順番を決めるやり方と、バージョン5.7とそれ以前ではINNER JOINに限り、STRAIGHT_JOINを用いて駆動表を選択することができることを紹介しました。 みなさんはこのSTRAIGHT_JOINを記述するやり方が複数あるのはご存知でしょうか？ 1つ目の記述は、INNER JOINの記述をSTRAIGHT_JOINに書き直すやり方です。たとえば、第97回で利用した下記クエリを参考にしてみましょう。 mysql
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億レコードになりました
はじめに マッハバイトでバックエンドを担当している @ayumu838 です。 今回は前回のような技術投資の話ではなく実務で使おうとしている話になります。 マッハバイトでは、求人ページに勤務地の最寄り駅に関する情報を掲載しています。 求人掲載の際に最寄駅は明示的に記載していただけることが多いのですが、一番近い最寄駅以外は意外と記載していただけないことがあります。 そこで、最寄駅から近い駅を自動抽出したいと考えたのですが、このようなニーズはマッハバイトに限ったものではないと思ったので、記事としてまとめてみました。 前提条件 実現するにあたり、以下を条件としました。 社内で使用している管理画面で使うだけなので、極力外部サービスに依存する箇所を減らす(≒専用のサービスを使わない) どこが近いかが分かれば良いので極端に高い精度は求めない たとえ、数十メートルずれていても駅同士の近さの関係にはほぼ影
MariaDBとMySQLの違い─定番データベース管理システムの比較 以前の記事で、ウェブサーバーのApacheについて、それがインターネットの発達にどれだけ寄与したか、そしてそのマーケットシェアが競合のNginx（※読み方：「エンジンエックス」）に押されつつあることなどをご説明しました。ApacheはLAMP（Linux + Apache + MySQL + PHP）の一つであり、インターネットの半分はLAMPにより成り立っていると言っても過言ではありません。 今回は、共通点はありつつも異なるデータベースであり、世界中の何百万ものウェブサイトで使用されているMariaDBとMySQLの違いについてご紹介します。 MariaDBはMySQLから派生したものですが、二つのデータベース管理システムは大きく異なります。 MariaDBは完全なるGPLライセンスですが、MySQLはデュアルライセン
Use the TempTable storage engine on Amazon RDS for MySQL and Amazon Aurora MySQL | Amazon Web Services
AWS Database Blog Use the TempTable storage engine on Amazon RDS for MySQL and Amazon Aurora MySQL August 2023: This post was reviewed and updated to reflect a new parameter change in MySQL Community 8.0.28 that impacts Amazon Aurora MySQL release. MySQL 8.0 has introduced TempTable as the new, default internal temporary table storage engine to speed up query processing. The MySQL query optimizer
実際のワークロードに近いSQLの負荷テストをmysqlslapのような感覚で行う方法を考える - GMOインターネットグループ グループ研究開発本部
こんにちは，S.T.です。今回は，お手軽かつ実際のワークロードに近い形でMySQLの負荷検証をする方法を考えます。お手軽にMySQLに負荷をかけるツールとしてmysqlslapがありますが，mysqlが実行するSQLはアプリケーションから実行するSQLとは性質が異なります。JOINなども絡めてアプリケーションが実行するSQLに近いSQLで負荷をかけられ，しかも簡単に実行できる，というものがあれば便利そうです。 1.mysqlslapとは mysqlslapは，MySQLの負荷をエミュレーションできるクライアントアプリケーションです。MySQLに接続して複数のクエリを実行し，その実行時間を計測することができるツールです。インストールも簡単で，たいていはLinuxディストリビューションのパッケージマネージャ経由でMySQLをインストールすると，一緒に入ってきます。実行も簡単で，いくつかのオプシ
って言うと語弊がありますが、デフォルトがPumaになってる昨今のRails、という意味で。 Rails Aurora フェイルオーバー でググると色々ヒットしますが、少々偏った情報が多いため、整理して残したいと思った次第です。 偏ったというのは、Unicornでしか使えない(古い)情報が多いから。 さて 問題事象をザックリ言うと フェイルオーバーによって、(Railsが)知らない間にREADERに降格してた元WRITERに対して更新クエリ投げちゃってエラーになる です。Auroraの各インスタンスはフェイルオーバーによって、IPアドレスはそのままでREADER⇔WRITERにスイッチするのですが、Railsがそれに追従できずにそのままコネクションをプーリングし続けるために発生する問題。 まず ググると行き着くのこちらでしょう https://github.com/sonots/active
FULLTEXT INDEX とは インデックス（索引）は、データベースの性能を向上させる方法の一つです。 しかし、通常のIndex では text ベースのカラム(CHAR型、VARCHAR型、TEXT型) から特定の文字列を検索する全文検索には向いていません。 それは、通常のIndex はカラムの値の一部ではなく、値全体に対する検索に最適化されているからです。 そのため、全文検索 (カラムの値の一部が一致している結果を取得) するには、別のインデックス FULLTEXT INDEX が必要です。 MySQL で FULLTEXT INDEX を利用するには MATCH 関数(*1)を利用する必要があります。 通常の LIKE 検索では、FULLTEXTIndex が利用されないため、速度的に不利です。(*2) (*1 DBMSによって様々、MS SQL では CONTAIN 関数を利用
この記事は MySQL Advent Calendar 2019 - Qiita 14日目の記事です。 三行で 初音ミク かわいい ポケットミクを制御するストレージエンジンを作った ことの発端 あやしいストレージエンジンができてきた pic.twitter.com/R1b1iDRWGT— miyakelp (@miyakelp_) 2019年11月11日 LTで紹介したMySQLでエアコンを動かすストレージエンジンですhttps://t.co/SCvlELIDXN— miyakelp (@miyakelp_) 2019年11月18日 MyNA望年LT大会2019にて，エアコンを動かすためのストレージエンジンを紹介させていただきました。 INSERTやUPDATEでエアコンのモードや設定温度を切り替え，SELECTで現在の状況を確認できるといったものでしたが， 当然MySQL単体で実現できる
InnoDB のロック機構について
n 番煎じネタですが、一度やってみたかったので手元で検証してみました。 特段新しいものは無いと思いますが、インテンションロックと各種ロックタイプを網羅的に挙動検証する記事は自分の観測範囲にはなかったはず？ 図を用意できたら読みやすかったと思うのですが、怠慢したので innodb_status_output_locks の出力でご容赦ください データセット今回使うデータセットです mysql> show global variables like ‘version’; + — — — — — — — -+ — — — — + | Variable_name | Value | + — — — — — — — -+ — — — — + | version | 5.7.26 | + — — — — — — — -+ — — — — + 1 row in set (0.00 sec)mysql>
皆さんはMySQLのパラメータや変数をどのように設定しているでしょうか？ MySQLやデータベースを運用する専用のチームの人たちがいて、秘伝のタレやノウハウが蓄積されて、その設定を使っているのかもしれません。しかし、そういったチームがなくMySQLのチューニングを行いたい場合に、何か手がかりが欲しいと思うこともあるでしょう。そんな場合に、簡単に使用できるMySQLのおすすめの設定を教えてくれる「MySQLTuner」を、今回は説明していきます。 検証環境 今回は、第125回 phpMyAdminでDockerで建てたMySQLにアクセスするで記載したdocker-composeを利用して作成します。手元で簡単に試せるように、GitHubの筆者のレポジトリにサンプルコードとして置いてあるので、気軽に試したい方はgit cloneして試してみてください。試すにはdockerとdocker-co
最終スコア 2335 で本戦出場です。スコアそのものは不完全燃焼感が否めないけどクッソ嬉しい。 isucon.net github.com レポジトリはこれ。チーム名は「ヌルポインターマリアユニバース」*1、メンバーは漏れと id:wtatsuru id:Pasta-K。やったことはこの repo みてくれ (master ブランチの内容がスコアのあれです) チームメンバーのエントリはこれら: wtatsuru.hatenadiary.com ビール2L飲んだけど記憶が生きてるうちの個人的反省箇条書き: なぞって検索のN+1を完全に2クエリ (O(1)) にできたのはよかった Revert "なぞってN+1関連をrevert" 再チャレンジ by polamjag · Pull Request #39 · tatsuru/isucon10q · GitHub ビッグデータ SQL テクニッ
InnoDBの通常のSELECTステートメントはロックを取得しません。よって、同一のトランザクション内にSELECTしたデータを使用して更新する際に、間に別のトランザクションがすでに同じ行を更新していると、ロストアップデートといったアノマリーが起こったりします。それを防ぐために、ロッキングリードを使用することでデータを保護することが可能です。 ロッキングリードには、排他行ロックを取得するためのステートメントSELECT...FOR UPDATEと、共有行ロックを取得するためのステートメントSELECT...FOR SHAREがあります。従来のMySQLでは共有行ロックを取得するステートメントSELECT...LOCK IN SHARE MODEが使われていました。MySQL 8.0からはこれがFOR SHAREに置き換わりました。 また、下位互換のためLOCK IN SHARE MODEは
週刊Railsウォッチ（20200804後編）「RubyKaigi Takeout 2020」9月オンライン開催、メールバリデータtruemail、Gitのmasterが変更可能にほか｜TechRacho by BPS株式会社
2020.08.04 週刊Railsウォッチ（20200804後編）「RubyKaigi Takeout 2020」9月オンライン開催、メールバリデータtruemail、Gitのmasterが変更可能にほか こんにちは、hachi8833です。「Kaigi on Rails」のプロポーザルがいっぱい集まったそうです🎉。 【CFPフォームクローズのお知らせ】 先程CFPフォームがクローズされました。予想を越えてたくさんの方にプロポ―ザルを提出いただき、運営チーム一同大変感謝しております。これから運営チームで選定を進め、8月中旬を目処に結果をお伝えする予定です。#kaigionrails — Kaigi on Rails (@kaigionrails) August 1, 2020 さらにこんなイベントもあったことに後から気づきました。 こんばんは！https://t.co/52TgXP8P
MySQL を使って EC2 r6g.large vs r5.large（mysqlslap 対決）をやってみた - Qiita
これは MySQL Advent Calendar 2020 21 日目のエントリです。 昨日は mita2 さんの「MySQL バイナリログをマスキングするツールを作ってみた」でした。 そして、↓の記事の続きでもあります。 AWS の EC2 Graviton2 インスタンスに MySQL をインストールしてみた（だけ） 前回はタイトルどおり本当に（R6g インスタンスに）MySQL をインストールしただけでしたので、今回はmysqlslapを使って R5（r5.large）インスタンスと比較してみます。 ※mysqlslapの説明は以下のページにあります（使うのは 8.0 用ですが基本は同じ）。 4.5.7 mysqlslap — 負荷エミュレーションクライアント（MySQL 5.6 リファレンスマニュアル） （いまさらですが、表中の--auto-generate-sql-load-t
オラクル、MySQLからオブジェクトストアにある最大400テラバイトのCSVファイルなどにクエリを高速実行できる「MySQL HeatWave Lakehouse」発表。Oracle CloudWorld 2022
オラクル、MySQLからオブジェクトストアにある最大400テラバイトのCSVファイルなどにクエリを高速実行できる「MySQL HeatWave Lakehouse」発表。Oracle CloudWorld 2022 オラクルは米ラスベガスで10月17日から4日間に渡って開催したイベント「Oracle CloudWorld 2022」で、MySQL HeatWaveからオブジェクトストアのデータファイルに対して直接クエリを発行できる「MySQL HeatWave Lakehouse」を発表しました（日本オラクルの発表）。 [News] Oracle Announces MySQL HeatWave Lakehouse with 17X Faster Query Performance vs. Snowflake and 6X Faster than Redshift on 400 TB Wo
Laravelには悲観的ロックの機能は備わってるけど、楽観的ロックの機能が用意されていないっぽいのでつくってみました。 そもそも悲観的ロック・楽観的ロックとは？？ 書きたい事から外れるので、ざっくりというと、、 悲観的ロック：自分がデータを取ってきた時点でロックをかけて、他の人にはそのデータを取ってこれないようにする。 楽観的ロック：誰でもデータを取ってこれるけど、先に更新した人が勝ちで、更新前のデータを後から更新しようとしてもダメ。 わかりやすく丁寧に説明してくれている記事はこちら↓ 「排他制御（楽観ロック・悲観ロック）の基礎」 「データベースの「ロック」という概念は2種類ある」 ということで、今回は「楽観的ロック」を作ってみます。 たまに見かける「他の人が変更してるので、画面更新して最新の情報を表示してね」的なメッセージが出るアレです。 今回は管理画面で「タイトル」と「本文」だけがある
awesome-mysql-performance - MySQL/MariaDBのパフォーマンスを改善するための情報をまとめたリンク集 | ソフトアンテナ
オープンソースのリレーショナルデータベース管理システム「MySQL」。その派生版である「MariaDB」とともに高速かつ無料で利用できることから高い人気を集めています。 本日紹介する「awesome-mysql-performance」は、それらデータベースシステムのパフォーマンスを最適化するための情報をまとめたリンク集です。 MySQLやMariaDBを単にインストールして使用するための方法を説明した情報はインターネット上に多数存在しますが、より深い見識が必要となるパフォーマンス改善のための情報はあまり多くはありません。 データベースサーバーを運用してみてパフォーマンスの低下に悩まされている方必見の情報といえそうです。 サーバーの設定からInnoDBの最適化 同リンク数には以下の情報が含まれています。 Ten MySQL performance tuning settings after
Percona XtraBackup: 高性能DBバックアップツール [DeNA インフラ SRE] | BLOG - DeNA Engineering
2024.02.27 技術記事 Percona XtraBackup: 高性能DBバックアップツール [DeNA インフラ SRE] by Kohei Okazaki #infra-quality #infra-delivery #stabilization #technical-verification #datastore #portability #pxb #mysql はじめに こんにちは、IT基盤部にてインターンとして活動している岡崎です。現在、私はパブリッククラウドチーム (以下、PCA)に所属しており、いくつかの施策に携わっています。 現代のビジネス環境において、クラウドリソースの柔軟な移動と管理は、事業継続性と革新性の両立に不可欠です。この重要なニーズに応えるべく、私たちPCAチームでは、クラウドリソースのポータビリティに関する総合的な施策を進めています。これは、アプリケー
![Percona XtraBackup: 高性能DBバックアップツール [DeNA インフラ SRE] | BLOG - DeNA Engineering](https://cdn-ak-scissors.b.st-hatena.com/image/square/6fd5a83c12bf78f093470b03c938b1bfbc9653e4/height=288;version=1;width=512/https%3A%2F%2Fengineering.dena.com%2Fblog%2F2024%2F02%2Fpca_portability%2Fcover.png)
for i in {1..100000}; do mysql -u root -e "INSERT INTO test.users set uuid=uuid(), id=uuid();"; done その他: innodb_buffer_pool_instances: 1 (単純化のため) 最適化の動作確認 次の順に操作を行い最適化/断片化の様子を確認します. ランダムInsert mysqldump optimize ランダムInsert MySQLが苦手とされるランダムInsertを領域管理の面から確認して行きたいと思います. ランダムInsert後の初期状態のディスク容量およびbuffer poolの状態を確認します. $ sudo ls -lah /var/lib/mysql/test/users.ibd -rw-r-----. 1 mysql mysql 44M 12月 23
Redshift Federated Query for RDS/Aurora MySQL をつかったType-2 Slowly Changing Dimensionの実装 - KAYAC engineers' blog
こんにちは。技術部の自称データエンジニアの池田です。 Redshift Federated Query for RDS/Aurora MySQL(Federated Query for MySQL)がめでたくGAになりました。 Federated Query for MySQLを使うと、RedshiftからAurora MySQLにクエリを発行し、その結果をRedshift上で利用することができます。 今回は、この機能を使ったType-2 Slowly Changing Dimension(SCD2) の実装の話をします。 aws.amazon.com TL;DR Change Data Capture（CDC）を実装・運用するほどじゃないけど、State Sourcingなテーブルの変更履歴を追跡したいときには、SCD2を使うと嬉しいです。 Federated Query for MyS
トランザクションのネストについてまとめてみました どう記述したらネストができるの？ ロールバックした時の挙動は？ などなどまとめてみました 自分がよく使うMySQLとRails(ActiveRecord)について記載します。他のDBやフレームワークでは多分話が変わりますのでご注意ください 前提 ネストしたトランザクションの挙動 ネストしたトランザクションって、正確な挙動がこうあるべきという決まりがあるのかどうかは筆者はよく知りません ここでは、以下のような挙動を満たすことを目的にします トランザクションの内部に、もう一つトランザクションを貼る 内側のトランザクションがロールバックした場合、外側のトランザクションには影響を与えない 外側のトランザクションがロールバックした場合、内側のトランザクションもロールバックする 内側だけコミットされてしまうと、外側のトランザクションから見ると一貫性が破
#長編 皆さん，初めまして．NTT SICの中園 (nikezono) です． この記事は 自作DBMS Advent Calender 2020 の 17 日目の記事です． この記事では，自作DBMSにトランザクションの機能を載せる際に必要な "Concurrency Control" (以下CC) について，プロトコルを設計する際に必要なノウハウを紹介します． プロトコルの考案という作業は，既に提案されているものを追実装するのとはかなり趣が異なります．具体的には，数理的な証明にかける作業の割合がかなり大きくなります．この作業を怠って，雰囲気で実装をしたり改変をしたりすると，ほぼ間違いなく処理の正しさが担保されません． しかし，得られるリターンは大きく，特定のワークロードを狙ったデータベースであれば，それに特化した性能を出すプロトコルを作ることが容易くできるようになります．特に，インメモ
While running Rails puma servers in production, we were seeing the incident that some old worker processes suddenly got stuck regardless of no change in the amount or trend of requests. I found out the root cause and reported it to the upstream. This issue still exists in Ruby 2.6.0 and can be found as far back as Ruby 2.5.0. If you just want a summary of the bug, see ruby-lang#17669. What Happene
プログラマのための技術情報共有サービスを爆速にせよ！― リクルート社内ISUCON 2021 winter レポート | Recruit Tech Blog
概要 まえがき 先日、「R-ISUCON 2021 Winter」が開催されました。ISUCON とは、お題となる Web サービスについてレギュレーションの中でパフォーマンス・チューニングを行い、ベンチマークの得点を競う競技です。（※） リクルート社内ISUCON はその名の通り、リクルートグループ内のエンジニアを対象とした社内 ISUCON に当たります。平時では合宿所を借りて一泊二日での開催でしたが、今回は2月26日のみの半日・オンラインでの開催となりました。 ※「ISUCON」は、LINE株式会社の商標または登録商標です。 お題 今回のお題は、「Niita」という架空の技術情報共有サービスになります。こちらはNTT コミュニケーションズ様が過去に開催した「N-ISUCON 2019」のお題をお借りしたものとなります。 モチーフとなったサービスと同様、下記の機能が実装されています。
MySQL5.6のオンラインDDLでメタデータロックがかかった話 - R-Hack（楽天グループ株式会社）
こんにちは、ラクマの宮崎です。 MySQLのオンラインDDLを実行する際にメタデータロックがかかってしまい困ったので、オンラインDDLとメタデータロックについて調べて手元で試したことをまとめました。 MySQLのバージョンは 5.6、ストレージエンジンは InnoDB です。 この記事の多くは、MySQL 公式ドキュメントの以下のページを参考に書いています。 公式ドキュメント①：14.11.1 オンライン DDL の概要 公式ドキュメント②：14.11.2 オンライン DDL でのパフォーマンスと並列性に関する考慮事項 DDLとは オンラインDDLとは オンラインDDLに対応しているDDL Ruby on RailsのMigrationでオプションをつける方法 オンラインDDLの注意点とWaiting for table metadata lock が発生するケース Waiting for
どうしたの？スタディストwebアプリグループでは、毎朝「エラーを見る会」というものを実施しています。「エラーを見る会」は、日々発生しているサーバーエラーを把握し、顧客影響(被害)を最小限にする目的の元、webアプリグループメンバーで行われている会です。そこでは、サーバー上で出たエラーを見て、「このエラーは早めになおしたいね」とか「このエラーはバックログに積んであとでなおそう」といった話し合いを行っています。 「エラーを見る会」で、以前より「ActiveRecord::Deadlocked」の発生を確認していましたが、詳細な原因を特定できていませんでした。そこで原因特定のために、ログ出力を行った事例について今回ご紹介します。 デッドロック情報を出力する弊社では、Amazon RDS Aurora MySQLを使用しております。 原因を調べるにあたり、ストレージエンジン(InnoDB)に関する
MySQL 8.0.23では、新たな機能としてInvisible Columnsが導入されました。この機能は、あるカラムを「存在はしているけれども明示的に指定しない場合は参照しないカラムとして扱う」ことができるようになっています。今回はこのInvisible Columnsの機能について見ていきましょう。 なお、似た機能である、invisible indexesについては第110回 Invisible Indexesを使って気軽にチューニングを始めてみるで紹介しておりますのでそちらをご参照ください。また、今回利用しているMySQLのバージョンは8.0.26となります。 Invisible columnsのあるテーブルの作成 Invisibleなカラムのあるテーブルを作成するには、InvisibleにしたいカラムにINVISIBLEをつけてCREATE TABLE文で実行するか、ALTER
MySQL のロック概観
MySQL を扱っているとたまに「このクエリだと何に対してロックを取るんだっけ？」、「デッドロックのエラー出てるけど原因がわからない」等悩むことがあるので、MySQL におけるロックの挙動を雰囲気だけでも理解したいなと思いました。 MySQL のロックまわりに関しては検索すれば既に多くの解説が得られるので、ここではそれらを参考にしながら自分にとってポイントになる部分を適宜まとめたりサンプルを実行したりしています。 なお途中出てくるサンプルは MySQL 5.7 (not 8.0) の REPEATABLE READ で確認したものです。 トランザクション分離レベル consistent read と locking read shared lock と exclusive lock InnoDB Locking DML 文は暗黙的に exclusive lock を取る 検索に使用された行
TL;DR 仕事でCloudSQLを触っているので知見を書く。 結論から言うと、GCP特有のポイントにいくつか気をつければ、あとはMySQLをチューニングするのと対して変わらない。 はじめに パラメータはインスタンスタイプを変えたところで自動で変わってくれない。 なので、ちゃんとしたいなら自分で変えてあげる必要がある。ログはデフォルトでは吐き出さないので出力する設定＆ファイルに吐き出す設定にする、など。 query_cache_typeもデフォルトoff。もろもろパラメータの設定はアプリケーションにあわせて設定していかないと、インスタンスタイプあげてもお金の無駄遣いになる。 ちなみにinnodb_buffer_pool_sizeだけはCloudSQLは自動で変えてくれる。db-n1-standard-1のインスタンスはメモリ3.7Gとかだけど、2Gとかに勝手にあげてくれた。 ディスクサイズ
はてなブログ独自の集計による人気記事のランキング。5月16日（日）から5月22日（土）〔2021年5月第4週〕のトップ30です*1。 # タイトル／著者とブックマーク 1 「スタートアップだからテストを書かない」は正しいか - An Epicurean by id:Songmu 2 マーソ株式会社を退職します - ikasama over technology by id:ikasamak503 3 2.4GHz帯無線LANのチャネルはぶつけてしまった方がよい - hgot07 Hotspot Blog by id:hgot07 4 ワクチン予約接種関連のシステムトラブルについてまとめてみた - piyolog by id:piyokango 5 世田谷区長の保坂展人氏がツイートした6月末期限のワクチンが、なぜか「デマ」あつかいされている件について - 法華狼の日記 by id:hokke
DBの負荷分散の手法について世の中にある手法についてかなり忘れてしまってきているので、最勉強を兼ねてざっくりと調べてみました。 設計の見直しとチューニング 負荷分散では無いですが、分散設計を考える前に、設計の見直しや、チューニングで救えるケースの方が多いと思うので少しだけ。 設計の見直しやチューニングをしないと、無限にリソースが必用になるので、ここはある程度きちんとやった方が良いと思う。（オンプレでは新規 HWを調達するのは難しいので、通常これをやるしかなくなる） DBの設計を見直す 正規化（データの冗長製の排除）だけだとデータ結合が必用になる事がありパフォーマンスに問題が出ることがある。非正規化（データを冗長に持つ）事も考える。 「スケールアウト」の所で後述するが、既存の DB でデータのリレーションが薄いものは、別 DBとして分割する事で負荷分散される事もできる。 DBのチューニング
MySQLには一時テーブルを利用するのに便利なCREATE TEMPORARY TABLE構文があります。これは利用しているセッション内だけで有効なテーブルを作成し、セッションが閉じたときに自動的にテーブルが削除される構文になります。 今回はCREATE TEMPORARY TABLE構文の挙動を確認していきましょう。なお、一時テーブルはInnoDB, MEMORY, MyISAM, MERGEストレージエンジンで利用可能ですが、今回は前提としてMySQL 8.0.17のInnoDBでの利用となります。 CREATE TEMPORARY TABLEを使って一時テーブルを作成する 一時テーブルを利用するには、CREATE TEMPORARY TABLES権限を持つユーザーがCREATE TEMPORARY TABLE構文を実施する必要があります。CREATE TEMPORARY TABLES
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
"innodb_flush_log_at_trx_commit" について - 元RX-7乗りの適当な日々
MySQL5.xではデッドロックだけど8.0では死なないよ - 41から始めました
Efficient MySQL Performance を読んだ
MySQL 8.0 の InnoDB の log_sys周り の話
第112回 知っておくと便利になるかもしれない小技 | gihyo.jp
SQLを使って位置情報から距離計算をする - LIVESENSE ENGINEER BLOG
MariaDBとMySQLの違い─定番データベース管理システムの比較
最近のRailsからのAuroraフェイルオーバー | DevelopersIO
世界一わかりやすい FULLTEXT INDEX の説明と気を付けるべきポイント
MySQL - 自作ストレージエンジンで初音ミクさんに歌っていただきましょう - こんぶのつけもの
第137回 MySQLTunerを使ってチューニングの足がかりを見つけてみる | gihyo.jp
#isucon #isucon10 予選参加記: 決勝行けましたの巻 - polamjaggy
第123回 ロッキングリードのNOWAITとSKIP LOCKEDオプションについて | gihyo.jp
Laravelで楽観的ロックをつくってみる - Qiita
MySQL InnoDBの領域最適化 - Qiita
トランザクションのネストの使い方まとめた（初心者向け） - Qiita
Concurrency Control Protocolをゼロから設計する - nikezono
Why puma workers constantly hung, and how we fixed by discovering the bug of Ruby v2.5.8 and v2.6.6
Amazon RDS Aurora MySQLでデッドロックのログを出力して読む方法
第158回 Invisible Columnsの使いどころ | gihyo.jp
CloudSQLとお友達になる | srockstyle
今週のはてなブログランキング〔2021年5月第4週〕 - 週刊はてなブログ
DBの負荷分散手法 | エンジニアの何でもメモ帳
第107回 CREATE TEMPORARY TABLEによる一時テーブルの利用 | gihyo.jp