MySQLの「temporary table (一時テーブル)」 と「tmp file(テンポラリファイル)」の違いと「Copying to tmp table」と「copy to tmp table」の違い
目黒川の桜きれいですね〜(*^^*)…なーんてガラじゃないことを言いたくなるくらい良い咲きっぷりでしたよ、エエ。で、来週末、花見に行くんだけど、まだ散らないでほしいっすねー。 えーっと、久しぶりにMySQLの記事。binlogを使ったリストア手法について。ネットを漁るとMySQLの運用に関する記事は多くヒットするんだけど、障害からのデータリカバリ、特にロールフォワードを扱った記事が思ったより多くない。おれは運が良いのか悪いのかMySQLのデータリカバリをしなければならないような局面に何度か直面しているので、手順について書いてみようかな、と。ここではMySQL〜5.5を対象にしている。直近での最新のメジャーバージョンはMySQL5.6なんだけど、おれはまだ5.6について大して知らない。5.6ならもっとイケてるやりかたがあるかもしれない。あったらいいな。 0. 環境 次のような環境を前提として
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パフォーマンスチューニングのためのインデックスの基礎知識に引き続き、MySQLのパフォーマンスチューニングについて学んだことをまとめ。 MySQLを使っていると、クエリが遅い理由をつきとめる必要が出てくる。 どうやって遅いクエリをつきとめ、改善すればよいかについて学んだのでまとめた。 下記のような基礎知識があればパフォーマンスチューニングをうまくやれる、と思う。 クエリ処理の基礎 MySQLがクエリを処理する手順 まずはMySQLがクエリを処理する手順を知っておく必要がある。 処理は以下のような流れで進む。 クエリキャッシュの中からクエリの結果を探す。見つかればそれを返す。 クエリを解析して構成要素に分解する。 クエリの構文が正しいことを確認 クエリについて基本情報を収集する。 クエリを基本的な要素に分解した後、何を実行すべきかを判断する。 クエリオプティマイザが動き始
Transactd Pluginは、MySQLおよびMariaDBのデータベースエンジンに対して高速なNoSQLインタフェースを追加するためのプラグイン。アクセス速度はSQLの数倍で、同社調べによると「NoSQLプラグインの中で最速」という。 Transactd Pluginの最大の特徴は、豊富な機能を備える点。ビズステーションでは、「従来のNoSQLプラグインの機能が限定的であったのに対して、Transactd Pluginはデータベースやテーブルの作成からトランザクション処理まで、これだけでアプリケーション全体を作成できるほどの豊富な機能を備えています」と説明している。 対応OSは、Linux(64Bit)、Windows(32Bit/64Bit)、およびMacなど。主な機能として以下が挙げられている。 データベースの作成、削除 テーブルの作成、変更、削除 フィールド、インデックスの定
ガリレオスコープ開発チームによる �最新Web動向、技術メモ ( Ruby, Rails, node.js ) です mysqlのconnection数はデフォルトでは100になっています。 メンテナンスの際にNavicatで接続すると、 ERROR 1040 (00000): Too many connections とのエラーが。。これは、アカンということで、パラメーターの調整を行いました。 下記を参考にしました。 http://satospo.sakura.ne.jp/blog_archives/tech/linux_server/mysql4_tune.html 現在の状態の把握とりあえず、今どうなっているか分からないので、確認用のコマンドを叩きました。 $ mysqladmin -u root extended-status | grep -E 'Max|Threads' | M
mysqldump クライアントユーティリティは logical backups を実行し、元のデータベースオブジェクト定義およびテーブルデータを再現するために実行できる一連の SQL ステートメントを生成します。 別の SQL サーバーにバックアップまたは転送するために、1 つ以上の MySQL データベースをダンプします。 mysqldump コマンドは、CSV、その他の区切り文字で区切られたテキスト、または XML 形式でも出力を生成できます。 複数のスレッド、ファイル圧縮、進捗情報の表示、および Oracle Cloud Infrastructure Object Storage ストリーミングや MySQL データベースサービス 互換性チェックおよび変更などのクラウド機能で並列ダンプを提供する MySQL Shell dump utilities の使用を検討してください。 ダン
MySQL 文字化けを防ぐ、文字コードの確認と設定 2007.01.15 MySQL 文字化けを防ぐために、文字コードの確認と設定を行う。 ■現在の文字コードの設定を調べる mysql> show variables like 'character_set%'; または、 mysql> status ■データベースの文字コード設定を調べる データベースごとに文字コードを設定できるので、現在の文字コードを調べる。 (テーブルごとではなく、データベースごと) mysql> show create database データベース名; 文字コードを指定してデータベースを作るには、 mysql> create databaase xxxdb default character set utf8; ■テーブルの文字コード設定を調べる テーブルごとに文字コードを設定できるので、現在の文字コードを調べる。
以下のようなピタゴラスの定理を使った指定した経度緯度に最も近いデータを取得するSQLは結構ありがちですが、CPU負荷が高く効率も悪いのでMySQLに標準搭載となった空間情報(geometry)を使ってみることにします。 SELECT * FROM loc ORDER BY power(abs(latitude - 緯度 ), 2) + power(abs(longitude - 緯度 ), 2) LIMIT 1 MySQLの空間情報(geometry)機能はPostGIS(Postgresカスタマイズ)に比べると貧弱なので、その為の工夫を行います。例えばここのとおりのままだと逆にSQLが遅くなります。 まずは、テーブル定義から 通常のテーブル CREATE TABLE IF NOT EXISTS `loc` ( `loc_id` int(11) NOT NULL auto_incremen
MySQLレプリケーションにおいて、スレーブをマスタとしてフェイルオーバーさせる時に やることをざっくりまとめてみた。 マスタでは障害等によりMySQLインスタンスが停止していることが前提。 マスタ1:スレーブ1構成の場合 1.マスタに昇格するスレーブにSTOP SLAVEを発行。 2.マスタに昇格するスレーブにRESET MASTERを発行。 3.スレーブに降格するマシンでCHANGE MASTER を実行し、 START SLAVEする。 もう少し詳しく書くと。 1.スレーブ側でIOスレッドでのバイナリログ受け渡しが完了する頃を見計らって、 STOP SLAVE IO_THREAD を発行。 mysql > STOP SLAVE IO_THREAD; “Has read all relay log”を確認できまるまで、SHOW PROCESSLIST の出力結果をチェックする。 2.ス
1.2 レプリケーションの動作レプリケーションでは最初にDBの内容を同期させた後、Masterサーバーで実行された更新系のクエリ(UPDATEとか)をSlaveに渡してSlaveでも同じクエリを実行していくことで、DBを同期させている(図1)。 Master側で実行された更新系クエリはバイナリログに蓄えられており、Slave側が接続してきたら、前回の接続からの変更分をSlave側に送信する。Slave側は受け取ったクエリを一旦リレーログに蓄えて順次クエリを実行してDBを同期させていく。リプリケーション動作にはBinlogDump,I/O,SQLの3つのスレッドが連携して動作する。 2.設定手順 (Master-Slave構成) 2.1 Master側の設定の確認Master側ではバイナリログを採取しておく必要があるので、Master側のmy.cnfにlog-binの設定が入っていることを確
MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA(高可用性) ディザスタリカバリ(サイト間レプリケーション) BI(レポーティングetc) という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション
MySQLサーバに限らず、大量のアクセスを処理するデータベースやアプリケーションサーバ群に対して、それぞれの環境に合わせたチューニングを行うことは企業システムにおいて必須の項目です。しかし「チューニングすべきパラメータとその最適値をどのように決定すればよいのか」、また「実際にチューニングを施すことによってどの程度効果があったのか」を把握することは意外に難しいものです。 ですが、敢えていえば答えは明瞭で、「定量的な情報収集と分析」の他にないでしょう。あらかじめ情報を収集しておけば、チューニング前後でのデータを比較することによってどのような変化が起きたのかを知ることができます。 本連載では、まずはMySQLサーバにおいて収集すべき情報を提示し、その後、それらを利用した基本的なパラメータについてのチューニング方針を紹介します。 また、今回はOSにCentOS 5.0、データベースにMySQL 5
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く