MySQLクエリキャッシュのステータス確認と削除 | mawatari.jp
たまにしか実行しないので、よく忘れるコマンド「MySQLクエリキャッシュのステータス確認と削除」についてのメモ。 まずは、クエリキャッシュのステータス確認について。 mysql> SHOW STATUS LIKE 'Qcache%'; +-------------------------+----------+ | Variable_name | Value | +-------------------------+----------+ | Qcache_free_blocks | 1 | | Qcache_free_memory | 21430536 | | Qcache_hits | 162 | | Qcache_inserts | 11960 | | Qcache_lowmem_prunes | 0 | | Qcache_not_cached | 24 | | Qcache_que
クエリキャッシュは切ったほうがいいんじゃなイカ？ : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の2日目は、昨日に引き続き、MySQLを骨までしゃぶるためのテクニックです。 ソーシャルゲームは一般サイトよりもDBへの更新クエリの割合が多くなりがちです。更新クエリが多いMySQLでは、通常は有益なクエリキャッシュが無益どころか有害になります。 そもそもキャッシュヒット率が低い。20%以下なんてこともザラにある しかもクエリキャッシュの更新はグローバルなロックを取得する からです。特に後者は問題です。ただの参照クエリもクエリキャッシュを更新する上に、更新クエリはクエリキャッシュの全エントリをチェックして、更新したテーブルに影響がありそうな全キャッシュをdiscardしていくためです。たとえばユーザーの行動力のようなパラメータを格納した参照も更新も多いテーブルでクエリキャッシュが有効になって
MySQLをFusion-io ioDriveで使うためのチューニング
「高嶺の花」の製品であったFusion-io ioDriveが、さくらインターネットの専用サーバプランにより月5万円でお手軽に扱えるようになりました。 今回は、このサーバを使ってMySQLのチューニングをしていきます。 使用したサーバ http://server.sakura.ad.jp/dedicated/expressg2.html さくらの専用サーバ エクスプレスG2シリーズ Fujitsu RX100 S7 Xeon 4Core SATA + ioDrive 320GB Memory 32GB ioDriveの接続とライブラリの確認 ioDriveの接続を確認 # lspci | grep -i fusion 01:00.0 Mass storage controller: Fusion-io ioDimm3 (rev 01) # rpm -qa | grep "iomemory"
日付、時刻の取得、フォーマット変更(MySQL、PostgreSQL、ORACLE)
SQLでの日付、時刻、曜日の取得方法、フォーマットの変更方法です。 各種データーベースによって取得方法に違いがありますので注意してください。 [toc heading_levels="2,3"] ■MySQL日付、時刻、曜日などその他色々な取得例 時間を取得する方法です。 使用例 mysql> select current_time; +--------------+ | current_time | +--------------+ | 06:43:15 | +--------------+ 日付の取得 日付を取得する使用例です。 mysql> select current_date; +--------------+ | current_date | +--------------+ | 2006-09-13 | +--------------+ 日付、時刻を取得する使用例です。 my
mysql replicationの復旧方法
Master_Log_File, Relay_Master_Log_Fileの意味は混同しやすいので、細心の注意を払ってください。また、それぞれのポジションの実態は、master.info, relay.infoというファイルです。 mysql レプリケーション 復旧シナリオ 事前準備 mysql レプリケーション 復旧シナリオ 事前準備 – mysqld_multi環境の構築 mysqld_multiを用いて、3つのmysqld(MySQLサーバ)を起動させます。動作確認のシナリオで使用する/etc/my.cnfの設定は以下の通りです。mysqld_multiの使い方は、mysqld_multiの設定方法を参照ください。 [mysqld] log-bin=mysql-bin relay-log=mysql-relay log-slave-updates master_info_repos
MySQLのスレーブサーバを別サーバに移設する時に注意すること · さよならインターネット
August 12, 2013 移設元のスレーブサーバのMySQLが停止できる場合 移設先のスレーブサーバで CREATE DATABASEして master.infoからreplユーザ作成して dumpファイルをバックアップサーバから持ってきて〜 などの作業を行わなくてもSLAVE STOPし MySQLを落とし変更が走らない状態にして MySQLのディレクトリを移設先にrsyncで渡した方が手間も処理速度も遥かに速い。 ただし、移設先でMySQLを起動してSLAVE STARTをすると Could not find target log during relay log initialization rellay.log このようにrelay_logが見つからないよ。というエラーが発生する。 16.2.2.1. The Slave Relay Log / MySQL 5.1 Refer
MySQL + ioDrive + XFSにおけるbinlogローテート問題 | 外道父の匠
前回の問題とはまた別件で、今度はbinlogのローテート切り替わりタイミングに更新クエリが停滞する、という問題を調べることになりました。 調査の過程で何を誤ったか、Twitterという魔法陣から最強クラスの重鎮魔神を召喚してしまい、恐れ多くも原因の特定と対応方針の決定ができてヘコヘコな感じでございます。 binlogローテート時の障害 数十分に１回、更新クエリが停滞してアプリケーションにエラーログが残るということから、他のエンジニアが、どうもbinlogの切り替わり時にそれが起きているっぽいことを特定してくれました。発生時は1～3秒は更新機能が停止するので、結構なレベルの障害ということでした。 binlogは1GBでローテートするように設定していたのですが、dstat -d でwrite容量を見ていると、確かに切り替わり時に800～900MBの書き込みを確認できました。 このことから、bi
MySQL Index勉強会外部公開用
12. © CROOZ,Inc. 12 １．INDEXとはなにか 何枚目がなにかを事前にメモっておけば良い！ スート ランク 位置 ハート Q 1 スペード 9 2 : : : ダイヤ 1 40 : : : スペード 6 45 なぜなら、要求は「カードを引く回数を最も少なく してスペード6を探すこと」 セコいとかおもうヒトはいるか もしれませんが何もセコいこ はしていないです。 前提条件など一切ないから このメモさえあれば位置を指定して1回引けば済む
開発環境のデータをできるだけ本番に近づける - クックパッド開発者ブログ
こんにちは。技術部の吉川です。 今回はクックパッドの開発環境構成、特に開発用データベースの構成についてご紹介します。 開発環境の構成 クックパッドのシステム環境は以下のようなフェイズに分かれています。 ※ これはcookpad.comの構成で、サブシステムや個別のサービスはその規模や特性に応じて構成が異なります。 development 開発者が実際に開発を行う環境です。クックパッドでは仮想環境は用いず、手元のマシンでRailsアプリケーションを動かして開発を行っています。 データベースはローカルではなく、開発者全体で共通の開発用データベースに接続しています。 test 手元でテストを実行する場合は、ローカルマシンのデータベースを利用します。CI（rrrspec）などの場合も同様で、テスト実行サーバーのデータベースが利用されます。 staging stagingといえば準本番環境として、本
『MySQL初心者に贈るインデックスチューニングのポイントまとめ2014』
サイバーエージェント公式ブログをご覧の皆さんこんばんは、インフラ＆コアテク本部の須藤(@strsk)です。普段はAmebaのソーシャルゲーム全般のインフラを見つつ、日本語ラップの啓蒙をしながら弊社社員を素材にコラ画像をつくったりしています。好きなAAは麻呂です。 はい、というわけで今回はMySQLインデックスチューニングの基本的な流れについてまとめてみました。 ソーシャルゲームは更新も参照もめちゃくちゃ多いです。数秒のレプリケーション遅延も致命的なので適切なテーブル、クエリとインデックス設計が重要です。（何でもそうですけど）インデックスが多くなると更新コストなどが懸念されますが、インデックスが正しく使われていないクエリを放置している方が悪です。そんなこんなで、割と例も偏ったりしてるかもしれませんがあしからず。 前提としてはInnoDBを想定しています。MyISAMはほとんど使っていません。
高可用性とデータ・シャーディングを実現できるMySQL Fabricとは？
MySQL Fabricは、MySQLサーバー群を管理する統合型のフレームワークです。MySQL Fabricを使うことにより、高可用性（HA）とデータ・シャーディングによる拡張性を実現できます。 MySQLのレプリケーション機能を使って高可用性構成を実現している場合、マスターのサーバーに障害が発生した時に、スレーブのサーバーを新しいマスターに昇格させるフェイルオーバー処理が必要になります。このフェイルオーバー処理を自動化するために、MySQL 5.6ではMySQL Utilities（※）にmysqlfailoverという機能が追加されました。 ※MySQL Utilitiesは、Pythonでかかれた便利なスクリプト集です。詳細は以下の記事も参考にして下さい。 ［参考］Pythonで作られた便利なコマンドラインツール MySQL Utilities mysqlfailoverを使うこと
AWS News Blog
New – Amazon EC2 Hpc7a Instances Powered by 4th Gen AMD EPYC Processors Optimized for High Performance Computing In January 2022, we launched Amazon EC2 Hpc6a instances for customers to efficiently run their compute-bound high performance computing (HPC) workloads on AWS with up to 65 percent better price performance over comparable x86-based compute-optimized instances. As their jobs grow more co
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（システム編）｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（システム編） こんにちは nob です。 前編 これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編） の記事から１年半が経過してしまいました。ちょっと長いお休みでしたが、その間に蓄えた MySQL パフォーマンス監視の実戦経験を（システム編）としてお届けいたします！ 今回の（システム編）で紹介するツボは 4 つです。（クエリ編）のツボに加えて、この4つに注目して頂ければ MySQL のパフォーマンス監視もバッチリです。 （ツボ１）Load Average < (1 + (cpu数-1)/3) （ツボ２）Checkpoint Age が水平線になったら要注意 （ツボ３）MyISAM は無いよね監視 （ツボ４）万能選手スローログ なお前編と同様この記事では監視ツールとして Cacti と Percona MySQL
(帰ってきた)InnoDBパフォーマンス最適化の基礎 | Yakst
MySQL Performance Blogの翻訳。Perconaのサポートエンジニアである筆者が、InnoDBのパフォーマンスチューニングの基礎について、ハードウェアやOSの選定からパラメータの推奨値まで解説する。 最近、2007年にPeter Zaitevが書いた「InnoDBパフォーマンス最適化の基礎」という記事を見つけた。これは素晴らしい記事で、読んでいると、MySQLとPercona Serversそして今日利用可能な全ての基盤技術に関して、6年近くの間に何が変わってきたのかを見直してみたいと思わせるものだ。 本当にたくさんのことが変わったものだ！この記事では、InnoDBの使用に効果的なパラメータの多くに、特にパフォーマンスの観点から焦点を当てる。私はサポートエンジニアで、Percona SupportではInnoDBパラメータの適切なサイズに関する質問がたくさん寄せられている
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編）｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編） こんにちは、インフラ担当新人の nob です。 サーバー監視ツールで MySQL を監視しているのにデータが多すぎて活用していない。という方はいませんか？その豊富なデータをパフォーマンス・チューニングに活用しない手はありません。今回はサーバー監視ツールのグラフを読み解いた実戦経験を元に、「これだけ見れば大丈夫」というツボをまとめてみました。 これだけ見れば大丈夫！ クエリ編 ３つのつぼと５つのグラフ （その１）監視ツールが何を見ているのか知る （その２）監視のキモ、グラフ３点セット (Questions, Lock Waits と Transaction Handler) （その３）グラフでチェックする SQL チューニング ( Select Type と Handler) シンプルでお勧め、サーバー監視グラフ化ツール
インスタンス内の全てのテーブルの統計情報を更新するshell - Qiita
#!/bin/bash #-------------------------------------------------------- # MySQLのテーブルすべてに、ANALYZEを実施する Innodb Only #-------------------------------------------------------- _DATE=`date +"%Y%m%d"` _HOSTNAME=`hostname -s` _START_DATE=`date +"%Y %m %d - %H %M %S"` # DB Config _DBHOST=hosuname _DBUSER=dbuserid _DBPASSWD=passwd _TMPDIR=/tmp mkdir -p ${_TMPDIR}/${_HOSTNAME} _TMP=${_TMPDIR}/${_HOSTNAME}/ANA
RDS: MySQLのログを取得する - aws memo
RDSのログファイルを取得出来るようになった Amazon Web Services ブログ: 【AWS発表】Amazon RDS - より簡単にログファイルにアクセス可能に ということで、RDS( MySQL )のログを取得する手順。 注意点として、RDS(MySQL)では4種類のログ（エラーログ、エラーランニングログ、ジェネラルログ、スローログ）にアクセスできるが、デフォルトではエラーログのみ有効となっている。 Working with MySQL Database Log Files - Amazon Relational Database Service 他のログを有効にするためには、Parameter Groupの以下を設定変更する必要がある。 パラメータ名デフォルト値変更値 general_log (null) 1 log_output TABLE FILE slow_quer
MySQL 5.6 でのレプリケーション遅延は危険 : DSAS開発者の部屋
MySQL 5.6 の検証中に MySQL 5.5 とは違うタイプのレプリケーション遅延を見つけたので紹介します。 MySQL のレプリケーションのおさらい MySQL のレプリケーションは次のような仕組みで動作しています。 マスターの更新トランザクションが binlog を書く スレーブの I/O スレッドがマスターに接続し、 binlog を取得し、 relaylog を書く. マスター側はスレーブからの接続を受け付けると(dump スレッド)、指定された場所から最新までの binlog を転送する binlog が追記されるのを待ってさらにスレーブに送る スレーブのSQLスレッドが relaylog を再生する MySQL 5.5 でよくあったレプリケーション遅延 マスターは並列してトランザクションを処理して、最終的にコミットした順で反映されれば問題ないようになっています。 一方、ス
誰も教えてくれなかったMySQLの障害解析方法 - Qiita
それほどDBに詳しくないアプリエンジニアが何かトラブった時にすぐさま行動して問題把握できるようになる情報を列挙しておきます。 開発時、障害時の対処療法やちょっとした定期監視方法などを対象にしています。 抜本的な対策などはインフラエンジニアさんにお任せしたほうがいいと思います。 DBはいろんな意味でこわいんでできれば触りたくないです＞＜ 事前確認 MySQLサーバーのシステム設定値を確認しておく 以下のようにサーバーのシステム設定値を確認できます。 mysql> SHOW GLOBAL VARIABLES; # ワイルドカード(%)を用いた絞り込み mysql> SHOW GLOBAL VARIABLES LIKE 'performance_schema%'
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
II-23-2. 統計情報の取得 | 日本OSS推進フォーラム