2017/10/08 phpcon 2017 https://joind.in/event/japan-php-conference-2017/session05-mysqlRead less
![片手間MySQLチューニング戦略](https://cdn-ak-scissors.b.st-hatena.com/image/square/538d6b3d421ff7a6f2bde1a53b583ca9bcf751fd/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fsparsetimemysqltuning-171008065714-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
トランザクションはACID特性を満たすと言われている。 そのうちA(Atomicity)はトランザクション内の操作をAll or Nothingとなるよう保証し、トランザクションが中途半端に実行されて(アプリケーションレベルから見た)データの整合性が失われることを防ぐ特性。またD(Durability)とはシステム運用中に起こる様々な障害からデータを守る(整合性を保つ)特性。 これらの特性を満たすためのDBMSの古典的なテクニックがすごく面白いので、それに関するMySQL(主にInnoDB)のパラメータ・パフォーマンスにどのような影響を及ぼすかを調べた(*'ω'*) なお紹介している技術は基本的に教科書に書かれていた技術で、実際にInnoDBに実装されているアルゴリズムとは異なることがある(とはいえベースにはなっている) 参考 障害の種類 DBMSの基本構成 データベースバッファ 概要 関
前提知識 Rails アプリにおいて、テーブルの追加やカラムの追加は簡単なものの、カラムの削除やリネームは慎重に行う必要がある。たとえアプリからそのカラムを参照してないとしても、いきなりカラムを削除するとエラーになる可能性が大いにある。 というのも Rails にはスキーマキャッシュというものがあり、テーブルのカラム情報をモデルがキャッシュしているからだ。このキャッシュはたとえばいわゆる N+1 クエリ問題を避けるために includes (eager_load) するときに参照される。 SELECT 句で t0_r0 のような機械的に別名が振られるようなクエリを見たことがある Rails エンジニアは多いと思う。 機械的に全カラムを取得するためにスキーマキャッシュを利用しているため、このようなクエリが実行されてる中でカラムを削除したりリネームしたりすると、スキーマキャッシュをもとに並べら
PostgreSQLとMySQL、使うならどっち? データベース専門家が8つの視点で徹底比較! オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう? それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース(以下、RDB)を選ぶのが最善なのか?」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ
xtrabackupでバックアップとっていたがいつまでたっても終わる気配ないという状況に。 バージョンはxtrabackup2.4.7。 xtrabackupにはIOを制御するための--throttleオプションがあって、これにやられた。 マニュアルの情報。 --throttle=# This option limits xtrabackup –backup to the specified number of read+write pairs of operations per second. @The xtrabackup Option Reference 詳細はここThrottling Backups。 簡単にまとめると、バックアップの時にread + writeを1 MB単位での1秒あたりの入出力操作の数を制御するとのこと。 単位はIOでデフォルトは0で制御しない。 xtrabac
MySQLのクラスター構成が一定規模を超えると自動フェイルオーバーに求められる要件が変化します。orchestratorはGitHubやBooking.comの大規模構成で自動フェイルオーバーを実現しており、数が多くなると顕在化する問題に取り組んでいます。本記事ではSeveralninesの高可用を実現する製品の比較記事への投稿に対するorchestratorの考え方や取組み方の違いについて紹介します。 [MySQL]原文 “MySQL High Availability tools” followup, the missing piece: orchestrator | code.openark.org (English) 原文著者 Shlomi Noach 原文公開日 2017-04-06 翻訳依頼者 翻訳者 taka-h 翻訳レビュアー doublemarket 原著者への翻訳報告未
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の
Faster MySQL replication with group commit and delay We’ve been having a problem with MySQL replication at VividCortex. Replicas periodically tend to fall behind and we couldn’t really figure out how to speed things up. It wasn’t about resources. The replicas have plenty of CPU and I/O available. We’re also using multithreaded replication (a.k.a. MTR) but most of the replication threads were idle.
リレーショナルデータベースで管理しているデータを Elasticsearch で検索・分析したい場合、Logstash が便利です。 Logstash とは?Logstash はオープンソースのサーバーサイドデータ処理パイプラインです。様々な数のソースからデータを取り込み、変換し、指定された任意のストア先にデータを格納することができます。 処理の内容はシンプルで、Input ステージでソース元の接続先情報を管理し、Filter ステージで変換をし、Output ステージで格納先接続先情報を定義します。Input 及び Output プラグインはデフォルトで様々なソースをサポートしています。そのため、Logstash を使えば、プログラミングレスで MySQL のデータを取り込み、変換し、Elasticsearch へインデックスすることができるのです。 事前準備MySQL と Elasti
フェイスブック 松信嘉範さんが登場! 世界中のユーザーがあらゆる情報を共有しているFacebook。ユーザーの投稿や「いいね!」などのアクティビティはメインデータベースのMySQLに刻々と書き込まれていく。同社はこのMySQLおよびストレージエンジンInnoDBに性能を高めるための独自の改良を加え、日々運用している。 サイトでは常に大量の書き込みが発生しておりデータはペタバイト級、膨大な処理をまかなうために大量のサーバーでシャーディング(分散)をしている。またMySQLデータベースの前にキャッシュを置き、多くの読み込みはキャッシュでヒットしてすぐ応答を返せるようにしている。 メインデータベースのストレージにはフラッシュストレージ(SSD)を使用。SSDは高いIOPS性能を出せるものの、価格はいまだにHDDよりも高い。なにしろ台数が半端ないので、ストレージ使用量(スペース)を少しでも減らすこ
別のエントリー書いてたら、前に誰かに聞かれたなと思ったのでメモ。 スローログが出力されるかどうかの判定は、 1. スローログが有効化されていること 2. log_slow_admin_statements = 0 で除外されるステートメントではないこと 3. (long_query_time以上の時間がかかっている) OR (log_queries_not_using_indexes にマッチする) クエリーであること 4. クエリーのExaminedが min_examined_row_limit 以上であること 5. log_queries_not_using_indexesにマッチしていることが決まっている場合、log_throttle_queries_not_using_indexes で設定された以上の時間が経っているかどうか 意外と4. が知られてなくて、どんなに時間がかかって
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの?」みたいな経験はありませんか?不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
その他のMySQLドキュメント 第39回 MySQLのドキュメントを探しにいこう と同じ出だしで恐縮ですが、MySQLのドキュメントを活用していますか? MySQLのドキュメントといえば 日本語版 MySQL 5.6 リファレンスマニュアル を想像されるかと思いますが、MySQLのドキュメントにはその他のものも数多くあります。通常の場合、検索エンジンなどを経由してたどり着く、Webページになっている日本語版のリファレンスマニュアル(オンラインリファレンスマニュアル)で十分な情報が得られるでしょう。 第39回では主に日本語版のオンラインリファレンスマニュアルのTIPSを紹介しましたが、今回はそれ以外の「知っているとごく稀に役に立つかも知れない」豆知識を紹介します。 過去のリファレンスマニュアルのありか ドキュメントのトップページ のラベルから「More」を選びます。 先頭の段落の「Archi
最近,環境ごとのデータベーススキーマの差分をチェックする機会があった.プロダクション環境とステージング環境ならまだしも,開発環境だと検証のために追加したインデックスがそのままになっていたり,開発が途中で止まってしまって日の目を見ることがなかったテーブルが残っていたり,そういうことって比較的あるのではないかなと思う.特に今の環境だと,マイグレーションの仕組みが整っていないという課題もあり,より一層,データベーススキーマに差分が出やすくなってしまっている. 今回は MySQL から公式に提供されている mysqldiff というツールを使ってデータベーススキーマの差分をチェックした. mysqldiff をインストールする mysqldiff は MySQL Utilities という MySQL の管理ツールパッケージの中に同梱されている.現在だと v1.6 が最新になっている. MySQL
timeout系パラメータはいくつかあるけれど 新規接続時のタイムアウト(connect_timeout)ではなく、一度確立した接続がタイムアウトで切断される現象に影響するタイムアウト設定のお話。 ERROR 2013 (HY000): Lost connection to MySQL server during queryにお悩みのアナタのためのヤツです。 「interactive_timeout」「wait_timeout」 ・interactive_timeout サーバーが対話型の接続で、対話型の接続を閉じる前にアクティビティーを待機する秒数。対話型クライアントは、mysql_real_connect() で CLIENT_INTERACTIVE オプションを使用するクライアントと定義されます。wait_timeoutも参照してください。 https://dev.mysql.com
サービスを作成する時に、文字型を使わずに作成することはあまりないと思います。MySQLを使った場合でも、サービスを作成しようとした時には、やはり文字列型を使うことになります。その際に間違えやすいのがCHAR型とVARCHAR型です。2つの型は似た名前をしているのですが、あまり理解してないで使ってしまうと、手痛い目にあってしまうことも少なくありません。 そこで今回は、CHAR型とVARCHAR型に関して、実際にどのように違うのかを紹介していきたいと思います。 検証環境 今回使用した環境は、CentOS7.1上にyumコマンドを利用してインストールしたMySQL 5.7.17で行っています。 まず最初に、今回使う検証用のデータベースを以下のように作成しました。 mysql> CREATE DATABASE characters; Query OK, 1 row affected (0.00 s
ソリューションエンジニアチームに所属する筆者が、今では様々な手法が存在するレプリケーション機能について、改めて特徴や注意点を解説しつつ、レプリケーションのよくある「誤解」に対してもお答えしています。 このブログ記事では、MySQL(および Percona Server)環境におけるレプリケーション手法に関して改めて考察を行いたいと思います。あわせて、時折見受けられるレプリケーションの間違った考え方についても考えてみます。 私がソリューションエンジニアとして働き始めてからというもの、沢山の情報が公開されているにも関わらず、レプリケーションに対する「誤解」や「不完全な理解」が無くならないことを日々感じていました。 そもそもレプリケーションとは何か? レプリケーションは、1つのデータベースにデータを蓄積するだけでなく、別のデータベースにデータを複製し、転送することを保証してくれる機能です (複製
ワンライナー mysql -u ユーザ -pパスワード -h 接続先 -e "SQL文" | sed -e 's/\t/\" \"/g' | sed -e 's/^/\"/g' | sed -e 's/$/\"/g' | sed -e "s/^/$(date '+%Y%m%d %H:%M:%S') /g" >> ファイル パスワードを生テキストで書くなって人はゴニョゴニョしてください。 追記:ゴニョゴニョするはなし、書きました。 MySQLで幸せになれるヤツの続き-パスワードを隠蔽する方法 - なからなLife 取りたい情報に応じて、権限が異なります。DBのroot相当の権限があるといいのですが、少なくとも「全スキーマへのSELECT」と「PROCESS」は必要になるはず。 何するやつ? MySQLにログインして、-eの後に指定したSQLを実行して、ログアウトする。 SQLの結果をパイプで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く