SRE Tech Talks #2 XFLAG スタジオにおけるSREの紹介、MySQL, InnoDB, THPのチューニングなど
くだらないことばかり書いているので、自分の知識の整理もかねて真面目なことをかいてみようと思う。 PostgreSQLは、セットアップ時のデフォルトの設定は、最近の高性能なハードウエアに合わせた設定になっていないのでハードウエアの性能に合わせて適切な値にしないとハードウエアの性能を引き出すことができない。 [max_connections] PostgreSQLがどれだけコネクションを待ち受けるかを指定するパラメーター、基本的にフロントエンドのWebサーバーの接続数と同じ数だけ用意する必要がある。 数値を増やすとOSのShared MemoryとPostgreSQLのWork_memの消費量が増えるので必要以上に大きくしない方が良い。 また1000コネクション同時接続とか大量のコネクションをさばく必要があるのならpgpoolを使用してコネクションプールをすることを考慮に入れる。 また、コネク
2ヶ月前にインフルエンザとウィルス性胃腸炎でひどくダメージを受けた増田(@masudaK)です。アメーバピグは2009年2月に始まったサービスで、FLASH・Javaで作られています。そして、データストアにMySQLを用いてます。本記事では、わたくしが2年ほど見続けているアメーバピグのDB環境について構成や、日々どのようにして問題と向き合っているかを紹介したいと思います。インフラ寄りの内容が多いため、アプリ寄りの話は弊社生沼の資料を御覧ください。 1. 構成と規模 1.1. 構成 まず構成ですが、読み書きはすべてマスターへ行うようにしています。そのため、スレーブには参照を向けず、ホットスタンバイとして使っています。バージョンに関しては2012年中旬までは5.0を使ってましたが、DC移転にあわせて5.5にあげました。ロック機能を用いたシャード構成をしてまして、2014年3月現在6シャードにな
1 データベース設定 1.1 基本設定 1.1.1 本節での記載内容について 1.1.2 基本設定詳細 1.2 スキーマ管理 1.2.1 本節での記載内容について 1.2.2 スキーマ 1.2.3 表、索引、表領域の管理 1.2.4 オブジェクトに関する禁止事項 1.2.5 オブジェクトのリリース方法 2 インスタンス設計 2.1 初期化パラメータ設計 2.2 REDOログ設計 2.3 表領域設計 2.3.1 システム表領域設計 2.3.2 一時表領域設計 2.3.3 UNDO表領域設計 2.3.4 ユーザー表領域設計 2.4 アーカイブログ領域設計 2.4.1 アーカイブログの意義 2.4.2 メリットとデメ
ツイート今日は、第 1 回のSQL アンチパターンの回から良コンテンツを提供しまくりなエンバカデロ・テクノロジーズさん主催の第 3 回 DB エンジニアのための勉強会に参加してきました。 今回は 漢(オトコ)のコンピュータ道で有名な漢の中の漢、 @nippondanji 氏がデータベース設計を徹底指南してくれるということで、元々 DB エンジニアがバックグランドのわたしとしてはいかないわけにはいかんだろう、と喜び勇んでいってきました！ 内容はというと下記の概要をカバーする内容でした。 リレーショナルデータベース（以下RDB）は登場してからかなりの時間が経っています。その名が示すように、RDBはリレーショナルモデルをベースに考案されたソフトウェアです。しかしながら、未だに現場ではRDBが使いこなされているとは言いがたく、リレーショナルモデルへの理解も進まず、誤った常識が跋扈しているのが現状で
DBエンジニアのための技術勉強会というイベントで、リレーショナルモデルにおけるDB設計について話す機会を頂いた。リレーショナルモデルは非常に重要であるにも関わらず、現場ではないがしろにされてしまっている。その結果、アプリケーションのロジックを上手くクエリで表現できず、開発現場では非効率な開発が行われ、多くの人がデスマ的な状況に追い込まれている。そういう危機意識について、これまで何度か本ブログでも書いてきたし、WEB+DB Pressで連載している動機もその点にある。リレーショナルデータベースはやはりリレーショナルデータベースとして使うべきだ。そのための鍵となるのが、DB設計である。 今回はなんと約2時間の持ち時間を頂いた。リレーショナルモデルについてはこれまで何度か話す機会を頂いたが、2時間というのは最長記録である。それに合わせてスライドもボリュームたっぷりのものになった。過去のスライドと
出典：日経コンピュータ 2012年12月20日号 pp.70-77 （記事は執筆時の情報に基づいており、現在では異なる場合があります） 2012年、DRAMでもフラッシュメモリーでもない“第3のメモリー”の量産出荷が始まった。DRAM並みに高速でありながら、フラッシュ同様に電源をオフにしてもデータが消えない「新世代不揮発性メモリー」だ。新メモリーによってコンピュータのアーキテクチャーは激変し、入出力（I/O）の大幅な高速化が実現すると共に、消費電力は激減する。 コンピュータには、高速だが電源をオフにするとデータが消える「主記憶装置（メインメモリー）」と、低速だがデータが消えない「外部記憶装置（ストレージ）」という2種類の記憶装置がある。 こんなコンピュータアーキテクチャーの常識が一変する可能性が出てきた。DRAM並みに高速でありながら不揮発性を備えた「新世代不揮発性メモリー」の量産出荷が始
まとめ読み！ PostgreSQL最近のアップデート：もう一度始めたい人のPostgreSQL（1） 依然としてシステムの中核を担っているRDBMS。その中でも、オープンソースの代表的なRDBMSである「PostgreSQL」を取り上げ、最近のアップデート内容とインストール方法などを紹介します。 最近、データベース界隈ではNoSQLが徐々に注目を集めていますが、現状では依然としてRDBがシステムの中核を握っているといえるでしょう。 「PostgreSQL」は代表的なオープンソースRDBMSの1つです。強大な影響力を持つ単一企業ではなく、有志の開発者とユーザーが集まるオープンなコミュニティによって活発に開発が続けられています。 1年に1回、機能追加を伴うメジャーバージョンアップを行うという安定したペースで10年以上開発が続けられているほか、年に数回、バグ修正を中心としたマイナーバージョンアッ
ストリーミング・レプリケーション (Streaming Replication) は、PostgreSQL 9.0 以降で利用できる、本体組み込みのレプリケーション機能です。参照/更新が可能な1つのマスタDBへの更新操作を、参照のみが可能な複数のスタンバイDBへ転送することで、データベースを複製することができます。スタンバイDBに更新結果が反映されるまでには若干の遅延がありますが、比較的 遅延は少なく、マスタDBへの影響も小さいレプリケーション方式です。 用途 ストリーミング・レプリケーションには以下の用途があります。 多数の参照クエリのサーバ間分散 マスタDB異常時の迅速なフェイルオーバー (切り替え) マスタDBのディスク故障に備えたリアルタイム・バックアップ PostgreSQL 9.1 での強化点 バージョン 9.0 の目玉機能として登場したレプリケーション機能ですが、9.1 では
第8回PGCon 2009.jp クラスタ会議のための予備知識 鈴木幸市，板垣貴裕（いたがきたかひろ） 2009-11-30
PostgreSQLで，システムテーブルを利用するための入門。 システムテーブルの使い方を覚えれば，自分が作ったテーブルの統計情報や，メタデータを取得する事ができる。 DBそのものの理解も深まる。 （１）情報スキーマ（人間に理解しやすい。調べ物をするとき便利） カラム一覧 制約一覧 （２）統計情報ビュー（パフォーマンス調整に便利） テーブル一覧 接続プロセス一覧 （３）システムカタログ（アプリからの利用向け） テーブル一覧 活用例 以下のSQLは，覚えやすいようにシンプルに記載してある。 いざという時に使うために，全部暗記しよう。 必要に応じてPostgreSQLの最新版のドキュメントを参照すること。 PostgreSQL日本語ドキュメント http://www.postgresql.jp/document/ （１）情報スキーマ（information_schema）を使おう Postgr
MHA for MySQL の導入を検討していて、まずは社内の技術者向けに、MHA for MySQL の概要を伝えようと、主に オフィシャルなドキュメント からポイントを抜粋して社内向けの Wiki に書いてみた。本当なら、オフィシャルドキュメント全体に目を通してもらうのがいいんだけど、英語なので、はじめの一歩としては敷居が高く感じる人もいるだろう、ということで。 特に外に出してまずい情報があるわけでもないので、このブログでも曝しておきます。 MHA の概要 MySQL エキスパートとして世界的にも著名な松信嘉範氏による、MySQL マスターの HA 化を行うためのツール。Perl 製。 最小限のダウンタイムで、データの不整合を防ぎつつ、マスターのフェイルオーバーを行う、というのが主な機能。 また、既に動作している MySQL に影響を与えることなく導入できる。 機能は大きくわけると以下
昨年、オタワでTim Child氏の発表を聞いて以来、実装できないものかと思って暖めていたアイデアがある。GPUの処理能力を使って、PostgreSQLの検索処理を高速化できないか？というものである。 特に複雑な計算を含むクエリの場合、Index-Scanに落ちないで、全件スキャンが走ることが往々にしてあるが、こういったケースで有効に作用するのではなかろうか？という着想である。 クリスマス休暇の間、割とまとまった開発時間を取る事ができたので、PostgreSQLのFDW(Foreign Data Wrapper)として動作するモジュールを作成してみた。 モジュールの名前は PG-Strom で、ドイツ風に『しゅとろ〜む』と発音する。 これは GPU の処理単位である Streaming Multiprocessor に由来する。 もちろん、現状のFDWのI/F前提なので、更新は不可能でソー
Postgres-XC is a write-scalable synchronous multi-master PostgreSQL cluster with the following features. 1) Both read and write scalability. 2) Configured with more than one server. 3) Complete global transaction and visibility management. Features Read/Write ScalabilitySymmetric (multi-master, synchronous) clusterTransaction management and consistent tuple visibilityParallel transaction execution
(PgDay2012発表資料) SQLにとって、なぜO/Rマッパーが重要かを説明した資料です。Read less
メインコンテンツに移動 ブックナビゲーション 目的別ガイド：導入検討編 目的別ガイド：インストール編 目的別ガイド：運用管理編 目的別ガイド：チューニング編 目的別ガイド：サポート編 目的別ガイド：内部解析編 RSS feed
本ページでは、PostgreSQLを運用していく上で必要な事柄を紹介します。「PostgreSQLの運用管理って何をしたら良いのだろう？」とお困りの方は、まず本ページでざっくりと運用の全体のイメージを掴んでみてください。各項目についてもっと掘り下げた情報は、リンク先の記事で紹介しています。 PostgreSQLの運用管理に必要なこと PostgreSQLの運用管理として必要な作業には何があるのでしょうか？運用要件によって必要な作業は変わってきますが、およそ以下の事項が挙げられます。 メンテナンス DBは、日々の運用により内部状態が変化していきます。常に一定のパフォーマンスを発揮するには、良い状態を保つためのメンテナンスが必要です。主に VACUUM や ANALYZE が該当します。 監視 異常を事前に察知する、もしくは発生後に原因を調査するために、DBやOSの状態を監視しておきます。適切
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く