mysqlでUnsafe statement written to the binary log using statement の警告が出た時の対処
2014年2月7日にリクルートテクノロジーズで開催された「第3回 ElasticSearch勉強会」でトークしてきました!前回の皆様の発表はKibanaに関する情報がメインでしたが、今回は検索技術中心のガチな内容でとても楽しかったです。 懇親会では今回発表したYamabikoのコア部分である fluent-plugin-mysql-replicator を実際に利用している方もいらっしゃるなど、感謝感激雨あられでした!ありがとうございます! その他にも2社合同で合同勉強会を開催しようといったお話を頂けるなど、実りのある時間を過ごせました。 発表テーマ 今回は「MySQLユーザ視点での小さく始めるElasticsearch」という発表です。 ログビジュアライズアプリであるKibanaを通じてElasticsearchに触れる方も少なからずおり、世間ではKibanaとセットで使う物であるような
MySQLにおいて、テーブルサイズやインデックスサイズ、レコード数、平均レコード長などの統計情報を知る上でshow table statusは定番です。ただ雑多な表示項目も多いので、たくさんのテーブルの統計を見る場合、必要な情報だけを返したいことは多いです。また全テーブルのうち、どのテーブルが一番大きいのかを知りたいとか、サイズが多い順に一覧表示したいとか、一目で分かるような情報がほしいことも多いです。 こういうときはinformation_schema.tablesを使うと便利です。以下の例では、appデータベースの全テーブルについて、「テーブルサイズ+インデックスサイズ」の大きい順に、ストレージエンジン、レコード数、平均レコード長、テーブルサイズ(MB)、インデックスサイズ(MB)などを返しています。 use app; select table_name, engine, table_
MySQLでは、各テーブル毎にストレージエンジンを設定する事が出来ます。 大体は、この2つのどちらかになるかと思います。 MyISAM:検索に強いらしい InnoDB:トランザクションが使えるらしい と言う事で、各テーブル毎に設定されているストレージエンジンを確認する方法です。 # mysql -u root mysql> use information_schema; mysql> select table_name, engine from tables where table_schema = DB_NAME; +--------------------+--------+ | table_name | engine | +--------------------+--------+ | hogehoge | InnoDB | | hagehage | MyISAM | | hige
でかいテーブルをdumpしてimportしなおすときに、alter enable keysで "repair with keycache" に悩まされてたんですが、MySQL Forums見てたらそのものズバリなのを見つけたのでメモ。 http://forums.mysql.com/read.php?35,155467,166902 ご存知の方には当たりまえな感じですが、自分はそもそも repair by sorting と repair with keycache の2通りのメッセージが出し分けられていること自体に気づいてませんでした。 mysqldump mysqldumpをつかってデータベースを(そのままimportに使える)SQL文に吐き出します。 % mysqldump -uuser -ppass -hhost hoge > hoge.sql このときhoge.sqlの中身はこん
先日大きめ(といっても500万行くらい)のテーブルにインデックス付きのカラムを追加しようとして痛い目にあったので調査。 大きめのテーブルにカラムやインデックスを追加するとどうなるか 今回は単純に、「ALTER TABLE 〜 」で追加しようとしました。追加するカラムは3つで、 varchar(255) インデックスなし varchar(255) ↓のdate 型カラムとマルチカラムインデックスの形式のユニークインデックスあり date インデックスあり SQL を実行し、状況を「SHOW PROCESSLIST」で監視していたら、1つ目のカラム追加で次のような状態に… 最初にState が「copy to tmp table」状態になり、次の状態に遷移するまで1時間かかる 次にState が「Repair with keycache」状態になり、完了までに1時間かかる 次のカラム追加に対す
MySQL Performance Blogの翻訳。インストール後に必ず設定を確認しなければならない設定パラメータ10つを挙げ、その意味を解説する。MySQLの設定変更時の、一般的な注意点も合わせて。 January 28, 2014 By Stephane Combaudon 我々がパフォーマンス監査の仕事をする時には、MySQLの設定のレビューと改善提案を求められる。大抵の場合、たくさんのオプションがある中でほんのいくつかの設定しか変更するように提案しないことに、多くの顧客は驚く。この記事のゴールは、もっとも重要な設定をいくつか挙げてみることにある。 既にこういった提案は過去にもしているが数年前のもので、それ以来MySQLの世界ではたくさんの変化があったのだ。 話の前に 熟練した人でも、重大なトラブルを引き起こすミスをしでかすことがある。従って、ここに挙げたものを盲目的に適用する前に、
MySQLが確保する各種メモリに関するパラメータの概要から、それらがどのように割り当てられるのかを知るための様々な手法まで、Perconaのサポートエンジニアが詳しく解説する。 January 24, 2014 By Nilnandan Joshi 「MySQLサーバのメモリ使用量」に関連するトピックスを書いたブログ記事は既にたくさんあるにも関わらず、MySQLのメモリ関連の問題のトラブルシューティングで混乱しなかった人はいないだろう。Perconaサポートのエンジニアとして、高負荷のサーバに関することや、メモリ使用量高騰でOOM killerが発動してMySQLサーバが停止したこと、あるいは「MySQLがどうしてこんなにメモリを食うのか分からない。どうやったら何にメモリが使われてるか分かるんだ?助けてくれ!」と言った問題を数多く見ている。 MySQLのメモリ使用量をチェックする方法はたく
新しいレプリカを作成するためにコピーするレプリケーションソースサーバーまたは既存のレプリカにスケジュールされたイベントがある場合は、それらが新しいレプリカで無効になっていることを確認してから開始してください。 ソースですでに実行されている新しいレプリカでイベントが実行されると、複製された操作によってエラーが発生します。 イベントスケジューラは、event_scheduler システム変数によって制御されます。このシステム変数のデフォルトは MySQL 8.0 の ON であるため、元のサーバーでアクティブなイベントは、新しいレプリカの起動時にデフォルトで実行されます。 新しいレプリカでのすべてのイベントの実行を停止するには、新しいレプリカで event_scheduler システム変数を OFF または DISABLED に設定します。 または、ALTER EVENT ステートメントを使用
「高嶺の花」の製品であった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"
-e を使う。 mysql -u root TABLENAME -e'select id from user where id=1' +----+ | id | +----+ | 1 | +----+ カラム名を表示したくない時、-N を使う。 mysql -u root TABLENAME -N -e'select id from user where id=1' +---+ | 1 | +---+値だけ欲しい時、 -B(と-N)を使う。 ※-B はタブ区切りで出力 mysql -u root TABLENAME -N -B -e'select id from user where id=1' 1複数カラム指定すると、 mysql -u root TABLENAME -N -B -e'select id, created_at from user where id=1' 1 2012-1
はじめに この記事は、MySQL Casual Advent Calendar 2013 7日目の記事です。 〜 Casual に記事を書けばええんやでヽ(´ー`)ノ 〜 私がMySQLで えっ?! っと思った下記エントリーの挙動が何故そうなってしまうのかを書きたいと思います。 InnoDBで行ロック/テーブルロックになる条件 MyISAM はテーブルロック、InnoDB は行ロックが掛かるというのは有名な話じゃないかと。 ただ、最近知ったのですが、InnoDB だとしても必ずしも行ロックになるわけではなく、テーブルロックになる場合もあるようですね。 ... InnoDB であってもユニーク制約 or インデックスが張られているカラムで検索した場合以外はテーブルロックになってしまうようです。これは注意しないと思わぬところでテーブルロックになってしまって大変なことになりそう! http://
All of Percona’s open-source software products, in one place, to download as much or as little as you need.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く