PostgreSQLとMySQLのメジャーバージョンアップのためのチートシート作った - そーだいなるらくがき帳中国地方DB勉強会 in 岡山の登壇資料です。 そのうちここで登壇動画が公開されることでしょう。 肝心なチートシートは以下のとおり。 PostgreSQL gist.github.com MySQL gist.github.com チートシートだけじゃわからない！困ってる！ Have Fun Techがバージョンアップのサポートしますのでお気軽にご相談ください。 have-fun.tech まとめ やっぱ中国地方DB勉強会は最高だぜ！
TiDBによる大規模ログデータ管理の挑戦！シャーディングなしで大量インサートをさばくには？ - LINE株式会社 - TiDB User Day 2023
イベント開催日：2023年7月7日 講演者：LINE株式会社 ITSC データベース室 MySQL 1チーム ソフトウェアエンジニア 大塚 知亮 氏 本スライドでは、TiDBで大量のログデータを管理するRDBとして、MySQL及びTiDBを検証した過程と結果、そしてオンプレでの運用方法について発表します。通常、超大量のデータ挿入や更新が発生するアプリケーションにMySQLを利用する場合、適切なデータ量や負荷を基準にシャーディングを行って対応します。しかし、それによってシャードを意識したクエリの発行が必要になるだけでなく、シャードをまたいだデータのジョインや整合性の担保に頭を悩ませることになります。この一つの解決策として、MySQL互換の分散データベースであるTiDBは魅力的な選択肢です。このスライドでは、LINEでシャーディングなしで高負荷案件に対応するために、どのように検証し、オンプレで
あなたの遅延はどこから？ SQLから！ 〜患部に止まってすぐ効くSQLレビューチェックリスト 年初め特大サービス号〜 - ANDPAD Tech Blog
あけましておめでとうございます！ 今年は異世界放浪メシのアニメが放送されるらしいので楽しみなバックエンドの原田 (tomtwinkle)です。 内部で運用しているSQLレビューチェックリストの一部を抽出し思いつきで追記して行った結果、結構な分量になってしまいました。 暇な時でも流し読みして頂けるとありがたいです。 Motivation SQLレビュー観点 大きくSQLが変更される修正の際にはEXPLAINをレビュー内容に加える 検索のキーにINDEXを使用しているか SQL発行回数がN+1(1+N)の構造になっていないか サブクエリを利用したSQLはパフォーマンス要チェック Viewの利用は基本的に禁止 CROSS JOINは禁止 WHERE句で十分に絞った検索をしているか 必要なcolumnだけSELECTしているか レコード数だけ必要な場合にCOUNT用のSQLを発行しているか 集計関
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
InnoDBの監視 ~ mackerel-plugin-mysqlを読み解く その2 - そーだいなるらくがき帳
この記事は 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とはプラグイン上で差分値計算をするかどうかです。 ◯ となっている項目はプラグインで
アマゾン ウェブ サービスの MySQL 用の JDBC ドライバーで、より高速なデータベースフェイルオーバーを実現
アマゾン ウェブ サービス (AWS) の MySQL 用 Java (JDBC) ドライバーの一般提供が開始され、Amazon RDS または Amazon Aurora MySQL 互換エディションのデータベースクラスターで使用できるようになりました。このデータベースドライバーが、データベースクラスターのステータスをモニタリングし、クラスターのトポロジーをキャッシュすることで、フェイルオーバー時間を最小限に抑えます。 ノードに障害が発生した場合の DNS 名解決の速度を向上させるためにキャッシュが使用したことで、フェイルオーバー時間が数分から数秒に短縮しました。 MySQL JDBC ドライバーは、MySQL Connector/J に基づいており、MySQL デプロイをサポートします。このドライバーは コミュニティ版の MySQL ドライバーとドロップインの互換性があり、Maven、
MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
![MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e9d48c3c6f38c2d5f71897d98efcb251289d1f9/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F07%2Fboard-755792_800.jpg)
5,500超のMySQLインスタンスを少人数で運用するには - LINEのDB運用効率化・自動化の取り組み - エンジニアHub｜Webエンジニアのキャリアを考える！
5,500超のMySQLインスタンスを少人数で運用するには - LINEのDB運用効率化・自動化の取り組み 大きなサービスであれば、それを支えるデータベースの規模もまた大きくなるでしょう。LINE社のデータベースの規模は、2021年11月時点でMySQLのインスタンス数5,500超。巨大なデータベースの運用を効率化、自動化するための工夫やノウハウをLINE社のDBAに聞きました。 日本国内だけで、8900万人以上という膨大なMAUを抱えるコミュニケーションアプリ「LINE」をはじめ、多くの大規模サービスを運営するLINE株式会社（以下、LINE）が取り扱うデータ量は膨大です。使用するデータベースの規模は、なんと、2021年11月時点でMySQLのインスタンス数5,500超。これほど多くのインスタンスを管理しているにも関わらず、同社でMySQLの運用に携わるDBA（Database Admi
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 のロック範囲は実行計画で変わるという話 - mita2 database life
最近、ANDPADでデータベース周りの技術顧問をさせて頂いています。ANDPADのエンジニアの皆さんから「データベースのロックまわりを詳しく知りたい！」というお話を受けて、先日、ロック周りの社内勉強会を開催しました。 SQLでは一般的なプログラミング言語と違って、ロックの制御を明示的に記述しません。ロックは暗黙的に（自動的に）データベースが必要なロックを獲得します。データベースのロックが わかりにくい・むずかしい と言われることが多いのはこういった背景があると思います。 MySQL のロック範囲は実行計画で変わる 更新対象の行がロックされるのは予測が付く方が多いと思います。 しかし、MySQL（InnoDB）では更新対象でなくても行がロックされることがあります。 このようなサンプルデータを使って説明します。 mysql> CREATE TABLE `lockt` ( -> `pk` big
MySQLのslow_logは何を計測して出力されるのか - tom__bo’s Blog
slow logの時間は何を計測しているのか？ きっかけ とあるMySQLインスタンスで1Gbのネットワーク帯域を使い切ってレスポンスタイムが悪化していたという話を聞いた。 確かに遅いがlong_query_timeを小さくしてもslow_logは特に出ていなかったため、どのクエリが問題なのかを特定しづらかったらしい。 これを聞いたときはRedisとかインメモリのDBならまだしもMySQLがストレージより先に1GbのNICを使い切ることがあるのかーと驚いた。まあ、100GB以上のメモリも珍しくないので、ほとんどメモリから結果を返していれば1Gb/s以上返すことは難しくなさそうではある。 だが、long_query_timeを小さくしてもslow_logにクエリが出力されなかったという部分は気になった。 具体的にlong_query_timeがどれくらいなのか、同時接続数はどれくらいでQPS
Give Love to Your SSDs - Reduce innodb_io_capacity_max!
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
未だ現役なPerl5.8 ＆ MySQL4.0とどう戦うか？ ライブドアブログが生んだカオスとレガシーからの脱却
未だ現役なPerl5.8 ＆ MySQL4.0とどう戦うか？ ライブドアブログが生んだカオスとレガシーからの脱却 Inside of Blog 15年熟成されたサービスの光と影、カオスとレガシーへの挑戦 #2/2 2019年11月20、21日の2日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2019」が開催されました。1日目は「Engineering」をテーマに、LINEの技術の深堀りを、2日目は「Production」をテーマに、Web開発技術やUI/UX、プロジェクトマネジメントなど、より実践的な内容についてたくさんのプレゼンテーションが行われました。「Inside of Blog; 15年熟成されたサービスの光と影、カオスとレガシーへの挑戦」に登壇したのはLINE 開発Bチームの大森貴博氏。後半パートとなる今回は、現役で稼
Percona LIVE 2019参加してきた (2日目) - tom__bo’s Blog
Percona LIVE 2019に参加してきました。 前回の続きで初日(Tutorial Day)から Session Day 1, 2の3日間のうち2日目(Session Day 1)の内容です。 おそらく発表のスライドが公開されることと思いますが、全体が非公開になるものや非公開になるページがあるかもしれないので、ここではあえて概要だけと会場の雰囲気や僕の感想を書こうと思います。 また、英語の聞き取り能力が高くないため、勘違いした内容を書いている可能性が多分にあります。あくまで参考程度に読んでください。 各発表ごとのサブタイトルは発表中のものもあれば、メモを忘れて僕が勝手に書いたものもあります。 (メモからの校生も面倒なので、ここで丁寧語は終了です) Session Day 1 (2日目) 1日目のスケジュール -> https://www.percona.com/live/19/sc
MySQLのmetricに関する話 | GREE Engineering
こんにちわ。せじまです。さいきん、ジム用に左右独立型スポーツモデルのBluetoothイヤホン買ったのですが、あまりの快適さに、ジムに通うモチベーションが５割増しになりました。 はじめに innodb_thread_concurrency について書こうかと思ったんですが、まずはその前に MySQL の metric の話から入ったほうが良いかなぁと思ったので、今回は metric の話を書こうと思います。はじめにお断りしておきますが長くなります。 弊社では７年以上前から、 MySQLのサーバ一台あたり（OS側のも含めると）200-300 以上の metric を だいたい15秒間隔で記録しています。最近はSSDなども使ってますが、むかしはHDDにmetricを保存していました。例えばMySQLのサーバ一台分のmetric表示した画面をキャプチャすると、次のような感じになります。 ※画像は
寿司とビールについて話し合いをしてきました | GREE Engineering
こんにちわ。せじまです。 さいきんの kernel について調べてたら、俄に Chromebook への興味が湧いてきたので、遅まきながら C302CA ポチってみました。わたしにとって人生初 Core M ということもあって、早く届かないかなと心待ちにしている今日このごろです。 はじめに MySQL5.7以前でおそらく最も有名な問題の一つに、Sushi-Beer issue of MySQL with utf8mb4 というものがあります。 忙しい人のために三行でまとめますと MySQL は character-set に utf8mb4 を指定すると、寿司やビールなどの絵文字を扱える。 ただ、Collation（照合順序） が utf8mb4_general_ci や utf8mb4_unicode_ci だと、絵文字を区別できない（寿司とビールの絵文字を区別できない）。 utf8mb
MySQL5.6と5.7のちょっとした違いとinnodb_thread_concurrencyの影響 - hiroi10のブログ
この記事はMySQL Casual Advent Calendar 2016の22日目です。 innodb_thread_concurrencyを最近のデフォルトである0と論理CPUコア数の2倍の48に設定した場合に観測出来た小ネタです。ベンチマークのtpsを載せていますが、1回しか取得してないので、割と誤差があると考えられるため、目安程度に見てください。 環境 CentOS 6.6(2.6.32-504.12.2.el6.x86_64) Xeon E5-2643 v2 3.5GHz x 2(2P12C24T) Memory 64GB (8GB x 8, DDR3 1866MHz) HDD SAS 300GB x 2 10k rpm(RAID1 BBU付き) FileSystem ext4 ベンチマークのデータ量はinnodb_buffer_pool_sizeに収まる量 メモリで殴るような
MySQLやSSDとかの話 その後 | GREE Engineering
こんにちわ。せじまです。 すべての基本は monitoring だと考えてるので、イマドキのウェアラブルデバイスいろいろ買っていろいろ計測してるんですが、最近のデジタルガジェット面白いなぁ２１世紀感パないと感心しまくってる今日このごろです。 ちょうど一年くらい前、 MySQL User Conference Tokyo 2015 で MySQLやSSDとかの話 前編を、 GREE Tech Talk #9 で MySQLやSSDとかの話 後編を、お話させていただきました。 その後どうなったの？ということで、後日談をまとめさせていただきました。（今回はMySQL成分それほどありません） 忙しい人のために三行でまとめると 以前の試みはわりとうまくいきました。 SSDの大容量化がさらに進んでますし、前回の経験を活かして、HDD積んだサーバの構成変更しました。 次のステージとしては、１ラックあたり
MySQL-5.6のMRRにデッドロック回避の夢を見る - ichirin2501's diary
この記事は、はてなエンジニアアドベントカレンダー2016の7日目の記事です。 昨日は id:haya14busa さんのSum/Union/Variant Type in Go and Static Check Tool of switch-case handlingでした。 こんにちは、ドラゴンボールのヤムチャ状態になってるichirin2501です。 技術ネタとして何を書こうかと考えたのですが、 またMySQLでロックの話をする運びとなってしまいました。 技術ネタついでに今年最後の記事になると思われるので、 この1年のアウトプットを振り返ってみますと、 はてな・ペパポ技術大会 〜インフラ技術基盤〜 計算量と僕とWeb開発 / computational complexity and I and Web // Speaker Deck Haten Engineering Seminar
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
A Dive Into MySQL Multi-Threaded Replication