MySQLのコネクションハンドリングの内部構造、スケール限界、そして最大コネクション数のチューニングなどについてご紹介します 免責事項 この記事はGeir Hoydalsvik氏によるMySQL Server Blogの投稿「MySQL Connection Handling and Scaling」(2019/3/19)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 この投稿では、MySQLのコネクション、ユーザースレッドおよびスケーリングについて取り扱います。MySQLがどのように動作するかをよりよく理解することで、アプリケーション開発者やシステム管理者が、トレードオフを踏まえた良い選択をできることでしょう。本記事ではコミュニティー版でコネクションがどのように動作するかについて述べますが、一方でスレッドプール、リソースグループ、あるいはコネクション多重化といった関
MySQLのZero Dateへの対処法
MySQLのZero Dateへの対処法 MySQLの0000-00-00 00:00:00は使ってはならない - そーだいなるらくがき帳 このエントリで、MySQLのゼロが含まれる日付け、いわゆるZero Dateについての問題点が色々挙げられているのを見かけたので、手短に対処法を述べておきたい。 Zero Dateが存在する理由なぜそんな厄介なデータが存在するのかというのは、開発の経緯や互換性といった深淵な理由からなので気にしないで欲しい。まあ、人間は完璧ではないので、人間が作るプログラムも完璧ではないということだ。 当然ながらSQL標準から外れているものは、例外的な使い方をしたい場合を除き、使うべきではない。アンチパターンも使い方次第という話もあるが、例外的な使い方は基本的に苦労が増えるので使うべきではない。 SQLモード実は、Zero DateはSQLモードで禁止できる。SQLモー
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
はじめに こんにちは、R&D本部アドプラットフォーム開発部の村岡です。 九州工業大学の先端情報工学専攻を予定通り修了してジーニーに17卒入社し、現在は主にGenieeSSPの開発を行っています。 以前こちらの記事を書きましたが、今回もMySQL関連の記事となります。 GenieeSSPについて GenieeSSPは、広告配信のレスポンスタイムを短くするために、数十万の広告枠の配信設定をすべてインメモリで保持しています。 全広告枠の配信設定はMySQLに保存されています。配信設定を変更する、つまりDBのデータを変更する方法は、現在の運用では4つあります。 営業担当や、広告運用チームなどが操作画面を使って更新する。 操作画面では対応できない場合などに、エンジニアの運用チームが手作業で更新する。 配信パラメータ最適化のためのバッチが更新する。 リリース時などにエンジニアが権限をもらって更新する（
MySQLのデータ型としてFLOAT型という型があるのですが、これを採用するのは混乱の元ではないか？と感じたので、その詳細を紹介します。 そもそもこの話のきっかけは「MySQLで6桁までの小数点を丸めずに扱うならFLOAT型を使うべき理由」という記事が目に止まったことです。それなりに人気を集めている記事のようですが、私の読んだ限りではFLOAT型を使うだけの根拠が文中から読み取れず、さらに類似する一次情報や英語記事が全く見つからなかったので、真偽が怪しい情報だと感じました。 その後、MySQL上で実験したりCソースコードを読んでみたりした結果、私の得た結論は真逆のものになりました。MySQL警察の方や浮動小数点数警察の方、追試や反論など頂けると助かります。 MySQLのFLOAT型とは MySQLのFLOAT型は原則としてIEEE754浮動小数点数単精度型（32bit）で実現されます*1。
この記事は Mackerel プラグインアドベントカレンダー(全部CRE） の20日目です。 qiita.com soudai.hatenablog.com それでは20日目は mackerel-plugin-mysql 第二弾、InnoDBの監視です。 mackerel-plugin-mysqlはRDBMSとして広く使われているMySQL専用のプラグインです。 第一弾はこちら。 soudai.hatenablog.com インストール方法や使い方、MySQLのデータ取得で使っているSQLは前回説明したので割愛します。 前回はMySQL全般に言える監視の内容でした。 今回はその中でもInnoDBに特化した内容でお送りします。 見れるメトリック それでは各グラフ定義ごとに説明します。 また表に出てくるdiffとはプラグイン上で差分値計算をするかどうかです。 ◯ となっている項目はプラグインで
はじめに GMOペパボ Advent Calendar 2017の15日目の記事です。 昨日の担当は@kurotakyさんによる RubyでBancor protocolのシミュレーションをするライブラリ"Bancor"を作っています - mo-fu note でした。 ブロックチェーン技術や仮想通貨はだいぶ前から話題になっていますが、それに関連した面白そうな取り組みをしているようなので、興味のある方はぜひご覧下さい。 さて、今回はMySQLのレプリケーションについて書いていこうと思います。 なぜMySQLの話なのか？ 私のTwitterアカウントを見ている人ならご存知かもしれませんが、ここ数ヶ月ほぼMySQL（とカレー🍛）のことしかツイートしていないくらいにはMySQLを触っていたからです。 最近、MySQLをアップグレードするためだけに生きてるみたいなところがある— ぱ (@purp
※ この記事はMySQL Casual Advent Calendar 2017の11日目の記事です。 A critique of ANSI SQL isolation levelsを読んで(読んだブログ)、MySQL(innodb)で分離レベルごとのanomaly(不整合)の発生について実験しました。使ったのはDockerで立てられる 8.0.3-rc-log MySQL Community Sereverです。 ここでは上記の論文であげられているanomalyとid:kumagiさんのブログ(いろんなAnomaly)で知ったread only anomalyが起こるかを分離レベルごとに試してみます。 最初に、それぞれのanomalyについての簡単な説明とkumagiさんのブログで使っている書き方を真似た図、それに対応するプランを整理し、(実行経過は省略してw)結果だけ書きます。 ※ こ
Since the purpose of a database system is to store data, there is close relationship with the filesystem. As MySQL consultants, we always look at the filesystems for performance tuning opportunities. The most common choices in term of filesystems are XFS and EXT4, on Linux it is exceptional to encounter another filesystem. Both XFS and EXT4 have pros and cons but their behaviors are well known and
サンプルサーバーのパケットフィルタは最初は以下の内容で設定し、セキュリティを確保しています。 tcp 22 はプライベートLANからの受信のみ許可 tcp 3306 は 153.127.195.113 のappサーバーだけに公開 tcp 80 は公開 tcp, udp の 32768-61000 はアウトバウンド通信の戻りパケット用に許可 ストリーミングのフラグメントパケットは公開 ip は基本拒否 また IP アドレスを打たずにホスト名でアクセス出来るように /etc/hosts に以下のエントリを追加しました。 153.127.195.113 app 153.127.203.176 db MySQLクライアントで接続して TCP の状態を観察 ここから実際にサーバーを動かして、その挙動を観察していきます。db サーバーに db1 データベースを作成し、アクセスユーザー user1 を追
インフラ部 & 技術部の青木峰郎です。 クックパッドでは全社的にAmazon Redshiftを中心としたデータ活用基盤を構築しています。 今日はその全体像についてお話ししたいと思います。 データ活用基盤の全体像 まず、以下にクックパッドのデータ活用基盤の全体像を示します。 大きく分けると入力が2系統、内部処理が1系統、出力が3系統あります。 入力はMySQLからのインポートとログのロードがあり、どちらも独自に構築したシステムで行われています。 DB内部のデータ処理はSQLバッチのみです。 そして出力は管理画面やBIツールからのアクセスとバッチ処理によるエクスポートに大別できます。 以下1つずつ説明していきましょう。 入力その1: MySQLインポートシステム MySQLからRedshiftへのマスターテーブル取り込みにも独自のインポートシステムを使っています。 このインポート処理には、つ
このエントリは GREE Advent Calendar 2015 22日目の記事です。 こんにちわ。せじまです。久々に 10inch の Android Tablet 買いかえたところ、USBがキャップレス防水になってるわお風呂で使っても内蔵スピーカーでそこそこ音量取れるわ水滴ついた状態でもタッチパネルの精度が高いわと、この分野に於ける技術の進歩ハンパないなと感心させられました。 はじめに 最近、 InnoDB の mutex 周りの実装に関心があるのですが、ちょっと調べてみたところ、自分が読みたいような内容の入門記事が、英語や日本語の blog などでは見つけられなかった、あるいは最近の記事ではなかったので、備忘録を兼ねて自分で書いてみることにしました。今回のゴールは、 SHOW ENGINE INNODB STATUS\G での次のセクションを読み解くところまでです。 -------
View the Project on GitHub はじめに サーバーアーキテクチャー B+ツリー インデックス Explain オプティマイザ トレース 論理変換 コストベース最適化 ヒント プランの比較 複合インデックス カバリングインデックス Visual Explain 変わりゆく実行計画(Transient Plans) サブクエリー 共通テーブル式(CTE)とビュー 結合 集約 ソート パーティショニング クエリーリライト 不可視インデックス クエリープロファイリング JSONと生成列 文字セット 非公式MySQL 8.0オプティマイザガイド 日本語版 原文URL: http://www.unofficialmysqlguide.com/ 翻訳者: doublemarket (@dblmkt) The Unofficial MySQL 8.0 Optimizer Guideの
Amazon RDS for MySQL と全文検索 | DevelopersIO
こんにちは、藤本です。 先日開催された Developers.IO 2017 で「Amazon Elasticsearch Service の使いドコロ」というタイトルで登壇しました。 Developers.IO 2017セッション「Amazon Elasticsearch Service の使いドコロ」で話しました #cmdevio2017 資料を作成する中で MySQL 5.7 から追加された全文検索の日本語対応に関して調べました。せっかくなのでまとめた内容をブログに書き出すとともに、RDS だとどこまでできるのかということを追加調査してみました。 MySQL 5.7 の日本語全文検索に関しては公式ドキュメントや、Oracle の方のスライドに詳しく説明されていますので、詳しく知りたい方は下記をご参照ください。 12.9 Full-Text Search Functions MySQL
Redirecting… Click here if you are not redirected.
よく、Auroraを採用しました、安定しています、移行してよかったです！とか見かけますけど、 なんで快適なのかをちゃんとわかって使ってんのかこの野郎ッp(｀･ω･´ﾒ)q 俺も全然わかってねぇッ( ･`ω･´) ということで、今回もいい感じに飽きてきたAuroraです。Aurora。少々気になっていた、ALTER TABLE周りについて興味深い数値が取れたので、その共有で御座います候。 MySQL5.6互換 AuroraはMySQL5.6互換というけれど・・・ Q:「MySQL と互換性がある」とはどういう意味ですか? これは、現在お客様が MySQL データベースで使用しているほとんどのコード、アプリケーション、ドライバー、ツールをほとんど、またはまったく変更を加えなくても Aurora で使用できることを意味します。Amazon Aurora データベースエンジンは InnoDB スト
去年書いたSoftwareDesignを題材にお話してください！って言われたので話してきました。 下の特集記事は１年経った今も現役で読める内容なので興味がある人はぜひ読んでみてください。 またRDBアンチパターンという連載をしていますのでこちらもあわせてご確認くださいっ！ gihyo.jp そして当日の資料はこちらです。 SoftwareDesignにしっかりとMySQLとPostgreSQLの違いについては触れているのでそこでは触れていない、ハマりどころや初めて両方のDBを知ったと言う人向けのカジュアルは部分を攻めました。 またDBだけの勉強会ですので普段説明するようなところは省略し、できるだけ経験談やコアの話に注力したつもりです。 このへんは資料に含まれて居ないので当日居た人たちだけの特典ですね！！ ということで実は今月は登壇3週連続だったのですが一段落しました。 来週はAWS Sum
The 5th column here shows VSZ usage (about 11GB). Note that the VSZ is likely to change over time. It is often a good idea to plot it in your monitoring system and set an alert to ping you when it hits a specified threshold. Don’t allow the mysqld process VSZ exceed 90% of the system memory (and less if you’re running more than just MySQL on the system). It’s a good idea to start on the safe side
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
