簡単にクラウドでDB(MySQL)環境が使える！Amazon RDSの使い方 - 元RX-7乗りの適当な日々
先日「Amazon RDS」に他ロケーション(Zone)で自動フェイルオーバーできるオプションが追加され、より実用性が高くなりました。また、"AWS Management Console"からの、Amazon RDSの利用がサポートされたことにより、利用の敷居もグッと下がりましたよね。 Amazon RDS – Multi-AZ Deployments For Enhanced Availability & Reliability | AWS News Blog MySQLに自動フェイルオーバー機能を追加したAmazonクラウド。オンラインのままパッチ当てやバックアップも － Publickey AWS Management Console Now Supports the Relational Database Service | AWS News Blog それに伴って、以前私が"@I
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン
Webサービスでは、世界中からのトラフィックを捌く必要があるため、いくらチューニングしようとも一台のRDBMSでは捌ききることが出来ないのが常だ。MySQLは最初からマスター・スレーブ型のレプリケーション機能が搭載されており、スレーブをたくさんぶら下げることによって参照の負荷をスレーブに割り振るというスケールアウトによってその問題に対処してきた。スレーブによるスケールアウトは、参照（＝PV）が多いWebサイトと非常に相性が良く、幾多のWebサイトにおいて実績を作ってきているし、まだまだ利用されている。 しかしながら、サイトのトラフィックが劇的に増加してくるようになると、レプリケーションによる負荷分散では追いつかなくなってきた。そこで人々がとった選択肢は、memcachedを利用することである。memcachedはインメモリ型の高速なKVSであり、参照・更新性能はMySQLより格段に高い。M
なければ INSERT、あれば UPDATE
間違って主キーと同じ値を含む行を挿入しようとしたらエラーを出して教えてほしいとき INSERT INTO test VALUES(1,100); とすると、ERROR 1062 (23000): Duplicate entry '1' for key 1 というエラーが出る。 間違って主キーと同じ値を含む行を挿入しようとしても無視して処理を続行してほしいとき INSERT IGNORE INTO test VALUES(1,100); とすると、Query OK, 0 rows affected (0.00 sec) と表示される。テーブルは変更されていない。 主キーと同じ値を含む行がないなら新しく挿入し、あるならその行を更新してほしいとき REPLACE INTO test VALUES(1,500); とすると、Query OK, 2 rows affected (0.00 sec)
データベースを用いたセッションデータ管理について - LukeSilvia’s diary
Web アプリケーションとは切っても切れないセッション機構。DB ベースでセッション管理を行なって得られた知見と、それを元に考察した結果をまとめてみます。 セッションデータの特性 DB で管理される他のデータに比べ、セッションデータはかなり特殊です。主な特徴は次のような感じ。 データが増加するのが速い 定期的な削除が必要 頻繁に更新される リクエスト毎に読みに行く必要がある このデータを読めないとアプリケーション全体にアクセスできない アクセス頻度が高いということです。あと、1つ目の特徴からセッションデータについては意識的に管理してやる必要があります。 現在の環境 アプリケーションの領域が少し特殊で、セッションデータがやたらたまります(ユーザ数何百万のサービスとかそういうのではないです)。 RDBMS MySQL 4.0.22 ストレージエンジン InnoDB レコード数 6千万 テータサ
KLab技術者ブログ:その12 忘れちゃいけないバックアップ
こんにちは。クーラーに当たりすぎて体調を崩してしまいました。 夏風邪は馬鹿が引くと言われますが、「まだ夏じゃないから馬鹿ではない」と自分に言い聞かせながら仕事します。 今回はバックアップと復元についてです。 いざというときの備えとして知っておかないといけない事ですね。 障害からの復旧 最も一般的な動機だが、実際には他の理由ほど重要でない事が多い。 ここでいう障害とは ハードウェア異常 ソフトウェア異常 データの誤操作による削除 サーバの盗難 サーバの物理的な故障 データの適切なコピーがあれば復旧するときに大変楽になる。 また、自然災害による障害は物理的な障害を与える事、さらには建物を破壊する事もある。 本当に万全を期すにはバックアップを別の場所に保管するとよい。 例には「1週間おきに自宅に持って帰る」とありましたが、自宅に持って帰るのは昨今では特に個人情報保護の観点からもセキュリティ上よろ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: MySQLによるタフなサイトの作り方: 佐藤真人, 桑野章弘, 岡田達典, 大黒圭祐: 本
rottel.net - このウェブサイトは販売用です！ - rottel リソースおよび情報
KLab技術者ブログ:その8 サーバ側でもチューニング