pt-online-schema-changeと5.6 InnoDBのオンラインALTER TABLE使い分け
この記事は MySQL Casual Advent Calendar 2015 の9日目です。 MySQL 5.6から InnoDBのオンラインDDL が導入されて久しいですが、一方で pt-online-schema-change (以下pt-osc）もまだまだ元気です。MySQL 5.5とそれより前ではpt-osc一択になりますが、MySQL 5.6とそれ以上の場合はInnoDBさんに任せるかpt-oscを使うかを選択することができます。 MySQL 5.6でもpt-osc一択にしても構わないといえば構わないんですが、いくつかのケースではInnoDBさんに任せた方が速くなったり安定したりするので、そのあたり解説していきます。 TL;DR ウチの使い分け。 原則 pt-osc スレーブの台数が多すぎない かつ データ容量が馬鹿でかくてストレージ食いつぶしそう または INSERT大杉で2
MySQL Performance Blogの翻訳。MySQLをリアルタイムなステータスを見るツールにinnotopがある。このシンプルだが非常に役立つツールの基本的な使い方や、複数のサーバの状態を一度に確認する方法などを解説する。 MySQLのGUIモニタリングツールは、我々のあらゆるニーズや状況にいつでもぴったりくるものとは限らない。そういったツールの多くは、MySQLサーバの現在の状態をリアルタイムに表示してくれるというよりは、データベースに過去どのようなことが起きたかの歴史的な見方を提供してくれるよう設計されている。CactiやZabbix、Ganglia、Nagiosといった素晴らしいフリーのツールもある。しかしこれらは、MySQLインスタンスで何が行われているかの詳細を見るためには正しく設定をする必要がある。そしてそういった設定は、素早くできるとは言い難く、面倒なものである(G
innotopはMySQLの状態をtop風に表示するコマンドです。 DBを1台ずつ見ていくぶんには特に使う必要性を感じなかったのですが、 サーバのグルーピング＆一括表示機能があることを知ってこれはけっこう便利なのでは？と思いなおしたので インストールからグループ設定までについて書いてみます。 サンプルイメージ グループ単位でクエリーリストを表示 グループ単位でレプリケーション状態を表示 インストール ここからダウンロードしてインストールします。 ※今回使ったのはinnotop1.8 ＆ CentOS5.Xです。 依存モジュールのインストール # yum install perl-DBI perl-DBD-mysql # rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-4.noarch.r
なかったらINSERTしたいし、あるならロック取りたいやん? from ichirin2501 www.slideshare.net 出来事 @ichirin2501 とりあえず何も考えずこの前のロックの話をSlideshareにあげてくれ！！— 柴崎優季 (@shiba_yu36) 2015, 8月 22 はじめに これは先日の社内勉強会で発表したもので、MySQLで特定の問題を解決したいときのノウハウ話です。特定の問題とは、アプリを書いてると「データがなかったINSERTしたい、あるなら排他ロックしつつ取得したい」という要望があったりします。例えば、あるユーザーアクションで初期値もパラメーターで渡されるケースで、データがないならそのままINSERT、既にデータがあるなら取得して状態に依存して更新処理を行いたい場合などです。見かけのロジックは単純に見えますが、MySQLでこれを実現しよう
InnoDB Deep Talks #2 (仮) でちっともディープじゃない話をしてきました
2024 ( 24 ) 9月 ( 4 ) 8月 ( 2 ) 5月 ( 1 ) 4月 ( 3 ) 3月 ( 6 ) 2月 ( 1 ) 1月 ( 7 ) 2023 ( 20 ) 12月 ( 3 ) 11月 ( 3 ) 10月 ( 1 ) 8月 ( 1 ) 5月 ( 2 ) 4月 ( 2 ) 3月 ( 3 ) 2月 ( 5 ) 2022 ( 27 ) 12月 ( 5 ) 10月 ( 1 ) 9月 ( 1 ) 8月 ( 5 ) 7月 ( 4 ) 6月 ( 3 ) 4月 ( 1 ) 3月 ( 3 ) 2月 ( 2 ) 1月 ( 2 ) 2021 ( 22 ) 12月 ( 4 ) 10月 ( 2 ) 9月 ( 6 ) 7月 ( 1 ) 6月 ( 3 ) 5月 ( 3 ) 4月 ( 1 ) 3月 ( 2 ) 2020 ( 42 ) 12月 ( 3 ) 10月 ( 2 ) 9月 ( 4 ) 8月 ( 3
Bind Peek をもっと使おうぜ！(柴田 歩) - JPOUG Advent Calendar 2014(Day 5) -歩 柴田
チューニングの基礎 それでは、具体的にInnoDBでどこをチューニングするべきかを見ていこう。 ■バッファプール 最も基本となるのがバッファサイズの調整だ。ワーキングセットが全てバッファに収まらない限り、バッファプールは大きければ大きいほど良い。その分ディスクアクセスが減るからだ。バッファサイズが小さいと、キャッシュミス時にディスクからReadするのに時間がかかり、I/Oがボトルネックになってしまう。予算のある限りメモリを目いっぱい搭載し、バッファプールに割り当てよう。InnoDBのバッファプールは、innodb_buffer_pool_sizeオプションで設定する。利用可能なメモリは、他の処理に必要な分を除いたすべてをInnoDBのバッファプールに割り当てよう。 innodb_buffer_pool=32G ここで一つ注意がある。innodb_buffer_pool_sizeはバッフ
MySQL 5.7で暗黙のデフォルトが変わりそうなはなし
Morgan Tocker というMySQLの中の人(MySQL Community Teamのひと)が 自身のブログ で、MySQL 5.7のデフォルト値の変更に関する意見を募集していたりする。 Proposed MySQL 5.7 defaults. Please send feedback! http://t.co/Uq6c7STXBE — morgo (@morgo) 2015, 1月 23 Proposal to change Replication and InnoDB Settings in MySQL 5.7 http://t.co/gr3AwwmoEv — morgo (@morgo) 2015, 1月 14 ので、ちょっと解説してみます。わたしが勝手に思っていることを述べているだけなので、詳しくは原文をあたってください。 まずはこっち。 Proposal to chan
今回から数回にわたり、TransactdのオペレーションとInnoDBにおけるロックについて解説します。 ロックについてはあまり良くわからなくてもとりあえずそれなりに動くアプリケーションは作れてしまいます。ですが、マルチユーザー環境でミッションクリティカルなアプリケーションを書くには、ロックの理解が不可欠です。ロックをうまく使って、矛盾や間違いのない読み書きをしつつ同時実行性も高いアプリケーションにしましょう。 その1では、Transactdを実装する上でMySQLのソースやドキュメントから得た知見を基に、InnoDBのロックの種類と分離レベルに応じてそれをどのように使うかをまとめてみます。 Index MySQLのトランザクション関連用語 MySQLのREPEATABLE-READ InnoDBのロック 行ロック (row-level locking) GAPロック GAPロック単体 ネ
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
この投稿はMySQL Casual Advent Calendar 2014の5日目の記事です。 @kamipo 質問させてください。このエントリーで COMPRESSED ではなく DYNAMIC を選んでいる理由はなぜですか？あまりDB詳しくないので参考リンクなどポインタを教えていただけるだけでも構いません http://t.co/9sC4lzLjXr— kiyoshi nomo (@kysnm) November 27, 2014 先週ツイッターでInnoDBのことを質問されまして、せっかくなのでアドカレのネタにしようと思いますってことでInnoDBのファイルフォーマット毎の違いをカジュアルに説明しようと思います。 InnoDBのファイルフォーマットBarracudaと新機能 InnoDBにはファイルフォーマットとして昔からあるAntelopeと新しいフォーマット(5年も前からあるの
InnoDBのREPEATABLE READにおけるLocking Readについての注意点
本日は、MySQL Casual Advent Calendar 2013の20日目である。というわけでカジュアルに小ネタを紹介しよう。 MVCC - Multi Version Concurrency Controlご存知の通り、InnoDBはMVCCを実装している。そのため、分離レベルがREPEATABLE READの場合には、行にロックをかけることなく、一貫した読み取りが可能になっている。 もし、あるトランザクションT1開始後に、別のトランザクションT2によって同じ行が書き換えられてしまった場合には、T1はロールバックセグメントにある古いバージョンの値を読み取ることができるので、T1内で実行したSELECTは常にT1開始時点のデータを参照することができるのである。大事なのでもう一度言うが、REPEATABLE READにおける単純なSELECTでは行ロックは必要ない。 Lost Up
MySQL 5.7.5で実装された オンラインでのInnoDBバッファプールサイズ変更（サイズ拡大編）
MySQL 5.7.5の新機能。 ログ貼ってたら長くなったので、バッファプールサイズを小さくするのは別エントリーへ。 理屈的には、 - バッファプールを大きくするとき * innodb_buffer_pool_chunk_size ごとに新しいページを確保しながらゴニョゴニョやる * この処理中は *バッファプールへの全てのアクセスがブロックされるよ* - バッファプールを小さくするとき * innodb_buffer_pool_chunk_size ごとにページを追い出しながらゴニョゴニョやる らしい。 http://dev.mysql.com/doc/refman/5.7/en/innodb-buffer-pool-online-resize.html しかしバッファプール大きくする時の動作はInnoDBのトラフィック全滅ですか使えNEEEE とか、「オンラインでバッファプールサイズを
チューニングの基礎 それでは、具体的にInnoDBでどこをチューニングするべきかを見ていこう。 バッファプール 最も基本となるのがバッファサイズの調整だ。ワーキングセットが全てバッファに収まらない限り、バッファプールは大きければ大きいほど良い。その分ディスクアクセスが減るからだ。バッファサイズが小さいと、キャッシュミス時にディスクからReadするのに時間がかかり、I/Oがボトルネックになってしまう。予算のある限りメモリを目いっぱい搭載し、バッファプールに割り当てよう。InnoDBのバッファプールは、innodb_buffer_pool_sizeオプションで設定する。利用可能なメモリは、他の処理に必要な分を除いたすべてをInnoDBのバッファプールに割り当てよう。 innodb_buffer_pool=32G ここで一つ注意がある。innodb_buffer_pool_sizeはバッファプー
※ブクマコメントで指摘頂いた箇所を追記しました＞＜ MySQL Casual Advent Calendar 2011 21日目の記事です。 前日は@sohgohさんの 「MySQLのUDFでカジュアルにファイル操作【MySQL Casual Advent Calendar 2011 20日目】」 でした。図や動画もあって見やすいですね！ 改めて自己紹介です。21日目を担当する、今回のカレンダーでNo.1カジュアルの座を狙っているid:oranie（オラニエ）です。 今回はMySQLもそこそこで、僕の名前の正しい読み方だけを覚えてくれれば今日は大丈夫です。 意図的に間違えている人もたまにいますが、心が汚れすぎていると思うのでお寺で座禅とかした方がいいと思います。 今までの記事を拝見させて頂き、みんな真面目に色々Tipsを書いているのでニッチ狙い＆初心者の僕は 「MySQLに対して、カジュア
よい機会なのでまとめておく。対象はMySQL5.6以下とMariaDB10.0以下。 (2014.12.3追記：以下の書籍にも記述した。) 要旨 MySQL/MariaDBのバックアップについて、相変わらず「InnoDBさえ使っていれば、FLUSH TABLES WITH READ LOCKは不要。よってバックアップ中に更新不可になることはない！」との主張が繰り返されているが、少なくとも5.6/10.0まではそんなことはない。 オンラインバックアップに関するロックの正確な記述 より正確に言えば「全データベース領域をバックアップする場合には、FLUSH TABLES WITH READ LOCKは必須。特定のInnoDBだけのデータベースやテーブルをバックアップする際は、この限りではない」。 なのだが、全領域のバックアップをしたい人に対してロック不要説を吹き込む人が未だにいる。 ロックの必要
サイバーエージェント公式ブログをご覧の皆さんこんばんは、インフラ＆コアテク本部の須藤(@strsk)です。普段はAmebaのソーシャルゲーム全般のインフラを見つつ、日本語ラップの啓蒙をしながら弊社社員を素材にコラ画像をつくったりしています。好きなAAは麻呂です。 はい、というわけで今回はMySQLインデックスチューニングの基本的な流れについてまとめてみました。 ソーシャルゲームは更新も参照もめちゃくちゃ多いです。数秒のレプリケーション遅延も致命的なので適切なテーブル、クエリとインデックス設計が重要です。（何でもそうですけど）インデックスが多くなると更新コストなどが懸念されますが、インデックスが正しく使われていないクエリを放置している方が悪です。そんなこんなで、割と例も偏ったりしてるかもしれませんがあしからず。 前提としてはInnoDBを想定しています。MyISAMはほとんど使っていません。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
