Oracle Databaseを用いて学ぶ�RDBMSの基本 （抜粋版） - JPOUG Oracle Database入学式 2016 Japan Oracle User Group (JPOUG) Oracle Database入学式 2016 – 保護者の方はご遠慮ください http://www.jpoug.org/?p=1546 で使用した資料の抜粋です。
とあるガラケーコンテンツのお話 オーソドックスなLAMP構成で朝起きるとログイン出来ないと問題が毎日あった エラー内容はDBに問い合わせができない状態 MySQLの接続がタイムアウトしていた データが流れないとサーバ側から接続をきられる apacheのpreforkで夜にアクセスが少なく、たまたま処理をしていなかったプロセスがmysqlにアクセスしようとすると接続できなかった Morning bugといわれるらしい pingやtcp_keep_alive設定すればいいのではと言われるが、超小規模サイトでは毎回接続すればいいのではという結論になった ちなみにこのサイトの会員数は10人！ -> それ全部テスト端末では？！ 企画の人は大きくなる！というが、大体大きくなる前に終了していくサービスが多いので、1つくらいあたった時に捻出できるリソースは準備しておく程度でいい 小規模しかやらない開発者は
InnoDB Pluginことはじめ。快適ストレージエンジン生活はじまる！
MySQL 5.1.38からMySQL本体にInnoDB Pluginバンドルされている。一部の先駆的なユーザー以外に、「InnoDB使ってますよ！」もしくは「検証してるよ！」という話をあまり聞かない。そもそもであるが、InnoDB Pluginってなんぞ？！という人が多いんではないかと思うのだが、実際はどうなのだろう？現在はRC版（リリース候補版）という位置づけのInnoDB Pluginであるが、一部影響度の高いバグが残っていたりしてGA版ほどの安定性は求められないものの、ほとんど実用に耐えうる品質になっているといえる。そんなわけで、今日は改めてInnoDB Pluginの使い方・使いどころについて説明するので、ぜひ皆さんの手でInnoDB Pluginを評価してみて頂きたい。 なお、以下の解説は現在の最新バージョンである、InnoDB Plugin 1.0.6を前提にしているので、将
MySQL Performance Blogの翻訳。Perconaのサポートエンジニアである筆者が、InnoDBのパフォーマンスチューニングの基礎について、ハードウェアやOSの選定からパラメータの推奨値まで解説する。 最近、2007年にPeter Zaitevが書いた「InnoDBパフォーマンス最適化の基礎」という記事を見つけた。これは素晴らしい記事で、読んでいると、MySQLとPercona Serversそして今日利用可能な全ての基盤技術に関して、6年近くの間に何が変わってきたのかを見直してみたいと思わせるものだ。 本当にたくさんのことが変わったものだ！この記事では、InnoDBの使用に効果的なパラメータの多くに、特にパフォーマンスの観点から焦点を当てる。私はサポートエンジニアで、Percona SupportではInnoDBパラメータの適切なサイズに関する質問がたくさん寄せられている
MySQL のチューニングで、my.cnf のオプション設定をいじっていたのですが、パラメータが大量にあって奥が深い。「現場で使える MySQL」のパフォーマンス・チューニングの章（13章, 14章）を読みなおしたのですが、そこからの抜粋中心で大事そうなパラメータの概要をまとめました。 現場で使える MySQL (DB Magazine SELECTION) スロークエリログ関連 log-queries-not-using-indexes これを指定すると、インデックスを使わないような処理（テーブルのフルスキャンなど）を行った全てのSQL文をスロークエリログに出力する。 slow_query_log スロークエリログを有効にするかどうかを指定。slow_query_log = 1 で有効になる。 logn_query_time 指定時間より長く実行時間がかかったSQL文をスロークエリログに
InnoDBのログとテーブルスペースの関係
InnoDBのデータ領域はログファイルとテーブルスペースという、切っても切れない2種類のファイルから構成されている。ログファイルは名前からするとただのログだから削除しても平気かな？と思って削除してしまうという問題が後を絶たない。そこで、今日はログファイルとテーブルスペースの関係について説明しようと思う。 InnoDBのログファイルは、別名WAL - Write Ahead Logと呼ばれるもので、名前を日本語に直すと「前もって書き込んでおくためのログ」とでも呼べるだろうか。InnoDBのテーブルに対して行われた更新は、全ていったんログに書き込まれるのである。トランザクションがコミットされると、innodb_flush_log_at_trx_commit=1が設定されていればログファイルに書き込みが行われる。0または2の場合には、ログバッファと呼ばれる領域にデータが保持される。その後、時間を
MySQL Performance Blogの翻訳。インストール後に必ず設定を確認しなければならない設定パラメータ10つを挙げ、その意味を解説する。MySQLの設定変更時の、一般的な注意点も合わせて。 January 28, 2014 By Stephane Combaudon 我々がパフォーマンス監査の仕事をする時には、MySQLの設定のレビューと改善提案を求められる。大抵の場合、たくさんのオプションがある中でほんのいくつかの設定しか変更するように提案しないことに、多くの顧客は驚く。この記事のゴールは、もっとも重要な設定をいくつか挙げてみることにある。 既にこういった提案は過去にもしているが数年前のもので、それ以来MySQLの世界ではたくさんの変化があったのだ。 話の前に 熟練した人でも、重大なトラブルを引き起こすミスをしでかすことがある。従って、ここに挙げたものを盲目的に適用する前に、
結論としてはinnodbテーブルの全データ量だそうです。 ここ最近はデータベースサーバのリプレースの案件の担当をしているのですが、サーバのサイジングをしていてふと、「どれくらいメモリあれば足りるんだろう」と疑問に思いました。 よく「サーバの全メモリの50％から70％くらい」とか「80％」くらいとか言われますが、それはどちらかというとスワップしないための限界値を示すものであって、理想値ではないですよね。それでいろいろ調べてみたところ、なかなか日本語で良いまとめがなかったので、まとめてみようと思います。 目次 そもそもinnodb_buffer_poolとは？ 使用状況を確認する(SHOW ENGINE INNODB STATUSでの計測) 適切なinnodb_buffer_pool_sizeは？（チューニング方法） そもそもinnodb_buffer_poolとは？ InnoDB maint
備忘録として、DSRによるLVSとkeepalivedの設定を段階的に書く。 前提は以下とする。 LVSの転送方式はDSR ネットワークは単一セグメントで超簡単なもの OSはCentOS6.5 今回はMySQLスレーブの死活監視＋管理について。システム構成はLVS+keepalivedの設定 3を参照。 TCPポートの監視：TCP_CHECK もっとも簡単な方法。LVS+keepalivedの設定 2で使った。 keepalived.confの一部を示す。 … 略 … real_server 192.168.1.201 3306 { weight 1 inhibit_on_failure # サーバ監視: TCPポートにアクセスするだけの超簡易的方法 TCP_CHECK { connect_port 3306 connect_timeout 30 nb_get_retry 3 delay_
MySQLバックアップ頂上決戦！！ LVMスナップショット vs InnoDB Hot Backup
スナップショットを使えばとある瞬間のディスクやファイルシステムのデータをいつでも後から参照することができる。しかもスナップショットの作成は一瞬だ。スナップショット機能を活用すれば最強のオンラインバックアップソリューションが出来るだろう。 しかし、スナップショットでバックアップを取るなんて危険な操作じゃないのか？！と不安に思われる方もいらっしゃるかも知れない。MySQL Serverが稼働中にいきなりデータだけをとってくるのだから、そのような疑問を持たれるのは頷ける。しかし仕組みさえ分かればスナップショットによるバックアップは怖くないということが分かるはずだ。そこで、まずはスナップショットによるバックアップの仕組みについて説明する。スナップショットを取る際の要件は次の通りである。 全てのデータを単一のボリュームに置くこと。つまり、一回のスナップショット操作でバックアップが取れることだ。 ディ
こんにちは。Lorentzcaです。3月ですがまだまだ寒いのでなかなか釣りに行けずテンションさげぽよです！ ↑↑ この度DBサーバー(物理マシン、MySQL)の引っ越しを行いました。 そのついでに、冗長化の仕組みをmhaとconsulを使った方法に変えたので紹介します。 はじめに まずは簡単に引っ越し前と引っ越し後の構成を比べてみます。 引っ越し前は以下の様な構成でした。 サーバー台数: 2台 MySQLフェイルオーバーの仕組み: 自作シェルスクリプト アプリの参照先を切り替える仕組み: keepalivedでvipを張り替えることで実現 引っ越し後は以下の様な構成になりました。 サーバー台数: 3台 MySQLフェイルオーバーの仕組み: mha アプリの参照先を切り替える仕組み: consulのdns機能を使って実現 なぜこのような構成にしたのか、話していきます。 引っ越し前に持っていた
2013年01月11日 keepalived + MySQL-MHA + xtrabackupで自動フェイルオーバーと手動フェイルバック(その１ keepalived編) はじめまして、アドウェイズエンジニアのイシマルです。 私がアドウェイズに入社してから7ヶ月が過ぎましたが、楽しいエンジニア生活を送っています。 アドウェイズに入る前は、大規模なシステムに携わったことがなかったのですが、 「やってみたい！」 と手を挙げると、私のチームのリーダーは、 何でも丸投げしてくれる、快く挑戦する機会を与えてくれるので、非常にありがたく感じています。 というわけで、今回は、初挑戦のKeepAlivedとMySQL-MHAを用いた自動フェイルオーバー(keepalived編)を検証してみましたので、ご紹介します！ ■サーバ構成 サーバ構成の要点をまとめると、 各サーバは仮想OSにし、物理サーバ1、
こんにちは。技術部の吉川です。 今回はクックパッドの開発環境構成、特に開発用データベースの構成についてご紹介します。 開発環境の構成 クックパッドのシステム環境は以下のようなフェイズに分かれています。 ※ これはcookpad.comの構成で、サブシステムや個別のサービスはその規模や特性に応じて構成が異なります。 development 開発者が実際に開発を行う環境です。クックパッドでは仮想環境は用いず、手元のマシンでRailsアプリケーションを動かして開発を行っています。 データベースはローカルではなく、開発者全体で共通の開発用データベースに接続しています。 test 手元でテストを実行する場合は、ローカルマシンのデータベースを利用します。CI（rrrspec）などの場合も同様で、テスト実行サーバーのデータベースが利用されます。 staging stagingといえば準本番環境として、本
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
