PostgreSQLバックアップの基本
Upcoming SlideShare
Loading in...5
×
 

PostgreSQLバックアップの基本

on

  • 12,081 views

2012年8月29日に開催された「バックアップ勉強会#1」でのセッション「PostgreSQLバックアップの基本」の講演資料です(講演動画は以下を参照ください...

2012年8月29日に開催された「バックアップ勉強会#1」でのセッション「PostgreSQLバックアップの基本」の講演資料です(講演動画は以下を参照ください)。
http://www.uptime.jp/ja/resources/techdocs/2012/08/pgbackup/

Statistics

Views

Total Views
12,081
Slideshare-icon Views on SlideShare
10,873
Embed Views
1,208

Actions

Likes
11
Downloads
157
Comments
0

6 Embeds 1,208

http://www.uptime.jp 1195
https://si0.twimg.com 7
http://mktredwell.hatenablog.jp 2
http://cache.yahoofs.jp 2
http://webcache.googleusercontent.com 1
http://pgsqldeepdive.blogspot.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    PostgreSQLバックアップの基本 PostgreSQLバックアップの基本 Presentation Transcript

    • PostgreSQLバックアップの基本 アップタイム・テクノロジーズ 永安 悟史 2012.8.29 Copyright 2012 Uptime Technologies LLC, All rights reserved. 1
    • 自己紹介• 永安 悟史 (ながやす さとし)• 略歴 – 1997年よりネットベンチャーにてインターネットサービス開発・運用に従事。 – 2004年より(株)NTTデータにて、並列分散データベースの研究開発、技術支援・保守 サポート業務を経て、データセンタの新規サービス開発、運用チームの立ち上げなど に参画。 – 2009年、アップタイム・テクノロジーズを創業。• 専門分野 – データベースシステム、並列分散システム、クラスタシステム – オープンソース・インフラ技術 – ITサービスマネジメント(ITIL)、ITインフラ運用管理(運用設計~運用)• 本業@アップタイム・テクノロジーズ – オープンソース導入サポートサービスの提供 – セミナ、トレーニングの提供 – 学習用コンテンツのオンライン販売 – その他、OSSおよびDB系技術コンサルティング Copyright 2012 Uptime Technologies LLC, All rights reserved. 2
    • PostgreSQLバックアップの基本 アジェンダ(1)アーキテクチャ概要(2)バックアップ・リカバリ ~ 概論(3)バックアップ・リカバリ ~ PITR(4)バックアップ・リカバリ ~ 運用(5)バックアップ・リカバリ ~ ツール Copyright 2012 Uptime Technologies LLC, All rights reserved. 3
    • (1)アーキテクチャ概要Copyright 2012 Uptime Technologies LLC, All rights reserved. 4
    • 実行中のプロセス$ ps -aef | grep postgrespostgres 22169 1 0 23:37 ? 00:00:00 /usr/pgsql-9.0/bin/postmaster -p 5432 -D /var/lib/pgsql/9.0/datapostgres 22179 22169 0 23:37 ? 00:00:00 postgres: logger processpostgres 22182 22169 0 23:37 ? 00:00:00 postgres: writer processpostgres 22183 22169 0 23:37 ? 00:00:00 postgres: wal writer processpostgres 22184 22169 0 23:37 ? 00:00:00 postgres: autovacuum launcher processpostgres 22185 22169 0 23:37 ? 00:00:00 postgres: archiver process archiving 00000001000000D60000004Epostgres 22187 22169 0 23:37 ? 00:00:00 postgres: stats collector processpostgres 23436 22169 16 23:42 ? 00:00:34 postgres: postgres pgbench [local] UPDATE waitingpostgres 23437 22169 16 23:42 ? 00:00:34 postgres: postgres pgbench [local] UPDATE waitingpostgres 23438 22169 16 23:42 ? 00:00:34 postgres: postgres pgbench [local] COMMITpostgres 24283 22169 5 23:45 ? 00:00:02 postgres: postgres postgres [local] idlepostgres 24301 22169 0 23:45 ? 00:00:00 postgres: postgres postgres [local] idlepostgres 24581 22169 0 23:45 ? 00:00:00 postgres: autovacuum worker process pgbenchpostgres 24527 22185 0 23:45 ? 00:00:00 cp pg_xlog/00000001000000D60000004E /var/lib/pgsql/9.0/backups/archlog/00000001000000D60000004E$ Copyright 2012 Uptime Technologies LLC, All rights reserved. 5
    • 実行中のデータベースクラスタ(ディレクトリ)# ls -ltotal 116drwx------ 10 postgres postgres 4096 Dec 14 19:00 basedrwx------ 2 postgres postgres 4096 Jan 10 00:28 globaldrwx------ 2 postgres postgres 4096 Dec 13 08:40 pg_clog-rw------- 1 postgres postgres 3768 Dec 14 15:50 pg_hba.conf-rw------- 1 postgres postgres 1636 Dec 4 13:47 pg_ident.confdrwx------ 2 postgres postgres 4096 Jan 10 00:00 pg_logdrwx------ 4 postgres postgres 4096 Dec 4 13:47 pg_multixactdrwx------ 2 postgres postgres 4096 Jan 8 10:14 pg_notifydrwx------ 2 postgres postgres 4096 Jan 10 15:43 pg_stat_tmpdrwx------ 2 postgres postgres 4096 Dec 28 14:41 pg_subtransdrwx------ 2 postgres postgres 4096 Dec 4 14:47 pg_tblspcdrwx------ 2 postgres postgres 4096 Dec 4 13:47 pg_twophase-rw------- 1 postgres postgres 4 Dec 4 13:47 PG_VERSIONdrwxr-xr-x 3 postgres postgres 4096 Jan 10 15:40 pg_xlog-rw------- 1 postgres postgres 18015 Dec 14 15:50 postgresql.conf-rw------- 1 postgres postgres 17952 Dec 14 15:05 postgresql.conf.orig-rw------- 1 postgres postgres 71 Jan 8 10:14 postmaster.opts-rw------- 1 postgres postgres 49 Jan 8 10:14 postmaster.pid# Copyright 2012 Uptime Technologies LLC, All rights reserved. 6
    • PostgreSQLの構成要素 PostgreSQLは、さまざまなプロセス・メモリ領域・ファイルによって構 成されている。 writer postgres logger wal writer autovacuum (バックグラウンド (リスナプロセス) (サーバログ) (WALライタ) (自動vacuum) ライタ)プロセス群 archiver stat collector postgres wal sender wal receiver (WALアーカイバ) (統計情報収集) (サーバプロセス) (レプリケーション) (レプリケーション) shared_buffers wal_buffers visibilitymap freespacemap トランザクションメモリ群 (共有バッファ) (WALバッファ) (ブロック情報) (空き領域情報) 制御情報ファイル群 テーブル インデックス トランザクション アーカイブ 設定ファイル ファイル ファイル ログファイル ログファイル Copyright 2012 Uptime Technologies LLC, All rights reserved. 7
    • PostgreSQLの基本的なアーキテクチャ 共有バッファを中心として、複数のプロセス間で連携しながら処理を行うマルチプロセス構造。 postgres (リスナプロセス) ( shared_buffers postgres 共 postgres 有 (サーバプロセス) バ postgres (サーバプロセス)クライアント ッ (サーバプロセス) フ ァ ) writer (バックグラウンド ライタ) wal writer (WALライタ) テーブル ファイル トランザクション インデックス ログファイル ファイル Copyright 2012 Uptime Technologies LLC, All rights reserved. 8
    • メモリ(共有バッファ) • ディスク上のブロックをキャッシュするメモリ領域 – ディスク上のブロックのうち、アクセスするものだけを読み込む – ディスクI/Oを抑えて読み書きを高速化 – すべてのサーバプロセスで共有 • 変更されたブロック(dirtyページ)は必要に応じてディスクに書き戻される – 契機は、「バッファ入れ替え、チェックポイント、バックグラウンドライタ」 – 変更の永続性はトランザクションログで担保する writer postgres 9 17 5 14 postgres postgres 共有バッファ 1 2 3 4 5 6 (メモリ) 7 8 9 10 11 12サーバプロセス 13 14 15 16 17 18 wal writer 19 ・・・・ トランザクション ログファイル テーブル/インデックスファイル Copyright 2012 Uptime Technologies LLC, All rights(ディスク) reserved. 9
    • データファイルの配置データベースクラスタ(PGDATA)領域 システムカタログ(global) 設定ファイル テーブルファイル テーブルファイル (postgresql.conf, pg_hba.conf) テーブルファイル インデックスファイル インデックスファイル その他制御ファイル等 インデックスファイル デフォルトテーブルスペース(base) トランザクションログ(pg_xlog) ユーザデータベース(OID) ユーザデータベース(OID) ユーザデータベース(OID) テーブルファイル テーブルファイル テーブルファイル インデックスファイル インデックスファイル インデックスファイル 外部テーブルスペース 外部テーブルスペース アーカイブログ領域 テーブルスペース領域 54.1. データベースファイルのレイアウト http://www.postgresql.jp/document/9.0/html/storage-file-layout.html Copyright 2012 Uptime Technologies LLC, All rights reserved. 10
    • (2)バックアップ・リカバリ(概論) Copyright 2012 Uptime Technologies LLC, All rights reserved. 11
    • バックアップとレストア/リカバリ• バックアップの難しさ – データはファイルの中にだけあるのではない – 通常は、共有バッファの内容が最新 – ファイルだけバックアップを取ってもダメ – ミリ秒単位で処理が進む中、すべてを一貫性を保った状態で• バックアップの種類 – コールドバックアップ – ホットバックアップ – PITR(アーカイブログ)バックアップ• バックアップ&レストア/リカバリはリハーサルをしよう! – 簡単な試験や手順書を作るだけで満足してはいけない・・・ – そのバックアップセットで本当にリカバリできますか? Copyright 2012 Uptime Technologies LLC, All rights reserved. 12
    • コールドバックアップ• サーバプロセスをすべてシャットダウンしてデータファイル全体をバックアップ – バックアップの間、サービス停止が発生する。 – リカバリの際には、バックアップ時のデータに戻る。 – ファイルバックアップなのでレストアが簡単。• 向いているケース – 前回バックアップ以降の更新データを、アプリログなどから復旧できる場合。 – ストレージスナップショットが一般化した今、案外現実的。• 向いていないケース – サービスを停止させられない場合。 – 障害発生の直前までの更新データが必要で、DB以外から復旧できない場合。 Crash ①サービス WAL1 WAL2 WAL3 停止 & ②障害発生 ファイル バックアップ ③レストア Index Table Copyright 2012 Uptime Technologies LLC, All rights reserved. 13
    • ホットバックアップ(pg_dump/pg_restore)• あるタイミングでデータの一貫性を保ちつつバックアップ(export) – シンプルかつ柔軟(テーブル単位のバックアップも可) – バックアップ時にサービス停止は起こらない。 – リカバリの際には、バックアップ時のデータに戻る。• 向いているケース – 前回バックアップ以降の更新データを、アプリログなどから復旧できる場合。 – データベース単位、テーブル単位でバックアップを取りたい場合。 – 論理バックアップが必要な場合(メジャーバージョンアップなど)• 向いていないケース – 障害発生の直前までの更新データが必要で、DB以外から復旧できない場合。 Crash WAL1 WAL2 WAL3 ①pg_dumpで ②障害発生 スナップショットを バックアップ ③レストア Index Table Copyright 2012 Uptime Technologies LLC, All rights reserved. 14
    • (3)バックアップ・リカバリ(PITR) Copyright 2012 Uptime Technologies LLC, All rights reserved. 15
    • 用語• オンラインWALファイル – pg_xlogディレクトリに配置されている(まだアーカイブされていない)WALファイル• アーカイブWALファイル(アーカイブログ) – アーカイブされたWALファイル• 完全リカバリ – (オンラインWALファイルを用いて)最新の状態まで戻すことのできるリカバリ• 不完全リカバリ – オンラインWALファイルを消失したため、最新の状態ではなく、アーカイブWALファイ ルまでしか戻せないリカバリ• ベースバックアップ(非一貫性バックアップ) – 共有バッファなどの状態に関係なく、ファイルシステムレベルで取得するファイルバック アップ。 – 「データベースのファイル」として一貫性の取れた内容である保証は無い。 Copyright 2012 Uptime Technologies LLC, All rights reserved. 16
    • アーカイブWALとPITRを用いたバックアップ• ベースバックアップ(基準点)+アーカイブWALファイル(更新差分) – サービスを継続したままベースバックアップを取得可能(非一貫性バックアップ) – クラッシュ直前の状態に復旧することが可能(完全リカバリの場合)• 向いているケース – データベースクラスタ全体の完全なバックアップを取りたい場合。 – クラッシュ直前の更新まで復旧させる必要がある場合。• 向いていないケース – データベース単位、テーブル単位などでバックアップを取得したい場合。 Crash WAL1 WAL2 WAL3 WAL4 ①ベースバック アップの取得 (非一貫性 ②WAL1を ③WAL2を ④WAL3を バックアップ) アーカイブ アーカイブ アーカイブ Index WAL1 WAL2 WAL3 Table レストア&リカバリに必要なファイル類 Copyright 2012 Uptime Technologies LLC, All rights reserved. 17
    • アーカイブWALとPITRを用いたリカバリ• ベースバックアップ(基準点)+アーカイブWALファイル(更新差分) – ベースバックアップをレストア後、アーカイブWALファイルを使ってロールフォワードリカ バリする。 – オンラインWALファイルが残っていれば、完全リカバリが可能。 – 前回のベースバックアップ以降、長期間が経過しているとアーカイブWALファイルが多 くなり、ロールフォワードリカバリの時間が長くなる。 – 所要時間は、「ベースバックアップレストア時間+アーカイブWALファイル適用時間」 ⑥リカバリ完了 WAL1 WAL2 WAL3 WAL4 ①ベース ⑤オンラインWAL バックアップを ②WAL1を ③WAL2を ④WAL3を (WAL4)を適用 レストア 適用 適用 適用 Index WAL1 WAL2 WAL3 Table レストア&リカバリに必要なファイル類 Copyright 2012 Uptime Technologies LLC, All rights reserved. 18
    • 障害とリカバリのシナリオ• データベースクラスタ(テーブルスペース)領域のロスト、障害 – ベースバックアップからデータベースクラスタをレストアし、アーカイブログを 用いてリカバリをする必要がある。 – オンラインWALファイルが残っている場合には「完全リカバリ」が可能。• オンラインWAL領域のロスト、障害 – PITRによるリカバリは「不完全リカバリ」となる。完全リカバリは不可。 – PostgreSQLが起動しなくなる可能性が高いため、ベースバックアップ+アー カイブWALからリカバリを実施(不完全リカバリ)。• アーカイブWAL領域のロスト、障害 – アーカイブWAL領域の障害は、サービスにはすぐには影響しない。 – 但し、アーカイブが失敗し始めると、オンラインWAL領域を圧迫し始める。そ のため、アーカイブを再開できるよう、アーカイブWAL領域を復旧させる必要 がある。 – また、障害が発生した際には、ベースバックアップ以降のすべてのアーカイブ WALファイルがないとリカバリできないため、再度、ベースバックアップを取 得する必要がある。 Copyright 2012 Uptime Technologies LLC, All rights reserved. 19
    • リストア、リカバリ手順• PostgreSQLサーバを停止する• 障害の発生したデータベースを保存する(可能であれば) – データベースクラスタ – テーブルスペース – オンラインWALファイル(残っている場合は必ず退避しておく)• ベースバックアップをレストアする• ベースバックアップ以降のアーカイブWALファイルを、アーカイブWAL領 域にレストアする• 退避しておいたオンラインWALファイルを配置する• リカバリ設定ファイル(recovery.conf)を作成する• PostgreSQLサーバを起動する(リカバリ処理は自動実行される) Copyright 2012 Uptime Technologies LLC, All rights reserved. 20
    • リストア、リカバリ概念図• ベースバックアップ、アーカイブWALファイル、オンライン WALファイルを用いてリカバリを行う。 通常稼働時 リカバリ時 ②アーカイブWALで リカバリ ②③ ログ適用 ③オンラインWAL でリカバリ Table WAL WAL Table WAL WAL Index Index アーカイブWAL アーカイブWAL 障害発生 リカバリ対象 データベース ①データを データベース レストア Table Table Index Index ベースバックアップ ベースバックアップ Copyright 2012 Uptime Technologies LLC, All rights reserved. 21
    • PITRのリカバリ動作状況[2011-12-12 06:32:52 JST] 31582: LOG: database system was interrupted; last known up at 2011-12-12 06:12:28 JST[2011-12-12 06:32:52 JST] 31582: LOG: restored log file "00000002.history" from archive[2011-12-12 06:32:52 JST] 31582: LOG: starting archive recovery[2011-12-12 06:32:52 JST] 31582: LOG: restored log file "000000010000000000000005" from archive[2011-12-12 06:32:53 JST] 31582: LOG: redo starts at 0/5000070[2011-12-12 06:32:53 JST] 31582: LOG: consistent recovery state reached at 0/6000000[2011-12-12 06:32:53 JST] 31582: LOG: restored log file "000000010000000000000006" from archive(...snip...)[2011-12-12 06:33:40 JST] 31582: LOG: restored log file "00000001000000000000000F" from archive[2011-12-12 06:33:47 JST] 31582: LOG: restored log file "000000020000000000000010" from archive(...snip...)[2011-12-12 06:34:49 JST] 31582: LOG: restored log file "00000002000000000000001A" from archive[2011-12-12 06:34:49 JST] 31582: LOG: could not open file "pg_xlog/00000002000000000000001B" (log file 0, segment 27): No such file or directory[2011-12-12 06:34:49 JST] 31582: LOG: redo done at 0/1A00511C[2011-12-12 06:34:49 JST] 31582: LOG: last completed transaction was at log time 2011-12-12 06:23:09.691458+09[2011-12-12 06:34:49 JST] 31582: LOG: restored log file "00000002000000000000001A" from archive[2011-12-12 06:34:49 JST] 31582: LOG: restored log file "00000003.history" from archive[2011-12-12 06:34:49 JST] 31582: LOG: selected new timeline ID: 4 Copyright 2012 Uptime Technologies LLC, All rights reserved. 22
    • (4)バックアップ・リカバリ(運用) Copyright 2012 Uptime Technologies LLC, All rights reserved. 23
    • バックアップ、リカバリの運用• 指定したサイクルで定期的にベースバックアップを取得 – ベースバックアップスクリプトをcron等で実行し、ベースバックアップを取得 – 世代ごとにサブディレクトリが作られてベースバックアップを保存 – 指定した世代数を超えたベースバックアップは削除 – もっとも古い世代のベースバックアップ以前のアーカイブログを削除• 障害が発生した場合は、ベースバックアップおよびアーカイブWALからリ カバリ – オンラインWALバックアップスクリプトを実行し、オンラインWALファイルを退 避する – リカバリスクリプトを実行し、最新のベースバックアップ、およびオンライン WALファイルをレストアし、リカバリ設定ファイルを作成する – PostgreSQLサービスを起動し、リカバリを実行する Copyright 2012 Uptime Technologies LLC, All rights reserved. 24
    • ベースバックアップの世代管理• 指定したバックアップ世代数に合わせて、ベースバックアップとアーカイブログを 管理する – 最新のベースバックアップを取得できたら、もっとも古いベースバックアップを削除する – アーカイブログは、もっとも古いベースバックアップ以前のものを削除する (例)ベースバックアップを3世代分保持する場合 コピー データベース スナップショット クラスタ (一時領域) アーカイブ、圧縮 第0世代 WAL Rotate 第1世代 Rotate アーカイビング 第2世代 第0世代を取得後に削除 第3世代 第2世代以降に生成された アーカイブログ アーカイブログを保持 バックアップ用ストレージ Copyright 2012 Uptime Technologies LLC, All rights reserved. 25
    • リカバリ時の動作• オンラインWALファイルを保存、最新の世代のベースバックアップからレストアし、 リカバリ実施に必要な設定ファイルを作成する – データベースクラスタに残っているオンラインWALファイルを保存する(①) – ベースバックアップからレストアする(②) – オンラインWALファイルを再度配置する(③) – リカバリを開始したら、アーカイブWALファイルを適用していく(④) データベース スナップショット ②レストア (一時領域) クラスタ 第0世代 WAL ①オンライン 第1世代 WAL保存 第2世代 ④適用 ③オンライン 最新WAL WAL配置 第2世代以降に生成された アーカイブログ アーカイブWALを保持 バックアップ用ストレージ Copyright 2012 Uptime Technologies LLC, All rights reserved. 26
    • アーカイブWALファイルの消し込み• ベースバックアップを取得すると、そのベースバックアップより前のアーカイ ブWALファイルは不要になる – 具体的には ”START WAL LOCATION” より前のWALファイル – ベースバックアップ②を取得したら、アーカイブWAL①は不要 – 但し、世代管理は必要 アーカイブWAL① アーカイブWAL② WAL WAL WAL WAL WAL WAL WAL WAL ベース ベース バックアップ① バックアップ②• 消し込みの方法 – pg_archivecleanupコマンドを使う(contribモジュール) – tmpwatchでタイムスタンプで判断(24時間以上経過したら削除、等) Copyright 2012 Uptime Technologies LLC, All rights reserved. 27
    • (5)バックアップ・リカバリ(ツール) Copyright 2012 Uptime Technologies LLC, All rights reserved. 28
    • pg_rman• NTT OSSセンターの開発したPostgreSQLバックアップツール – バックアップの取得 – リストア/リカバリの実行 – バックアップセットの管理 – D2D (Disk to Disk)のツール• 運用方法 – バックアップ取得(full、incremental、archive) – バックアップ検証(validate) – バックアップ消込(delete) – レストア/リカバリ実施 pg-rman - PostgreSQL Recovery Manager - Google Project Hosting http://code.google.com/p/pg-rman/ Copyright 2012 Uptime Technologies LLC, All rights reserved. 29
    • Barman• 2ndQuadrantの開発したPostgreSQLバックアップツール – バックアップの取得(複数サーバ、ネットワーク経由) – リストア/リカバリの実行 – バックアップセットの管理 – D2D (Disk to Disk)のツール – 複数サーバを対象としたバックアップ管理が可能 Barman - Backup and Recovery Manager for business critical PostgreSQL databases http://www.pgbarman.org/ Copyright 2012 Uptime Technologies LLC, All rights reserved. 30
    • Q&ACopyright 2012 Uptime Technologies LLC, All rights reserved. 31
    • さらに詳しくなりたい方は• PostgreSQLアーキテクチャ入門(自習用教材) – 内容:プレゼンテーションを録画した動画、及び使用しているスライド – 動画時間:約55分 – スライドページ数:54ページ – ファイル形式:MP4(動画)およびPDF(スライド)• OSDL DBT-3によるPostgreSQLの性能評価(SATA HDD&SATA SSD編) – 内容:技術検証レポート – ページ数:54ページ – ファイル形式:PDF いずれも http://www.uptime.jp から購入できます。 Copyright 2012 Uptime Technologies LLC, All rights reserved. 32
    • PostgreSQLパフォーマンスチューニング入門• 日時:2012年9月14日(金) 14:30~17:30 (約3時間)• 場所:クロスコープ青山 セミナールーム (東京メトロ 外苑前駅)• 概要 – PostgreSQLを利用する際に必要となるパフォーマンス管理およびチューニングについて、その仕組み や手順などの基本的な知識を獲得することを目的とします。• 対象 – PostgreSQLを使っているアプリケーション開発者の方 – PostgreSQLをこれから使い始めるデータベース管理者の方 – 現在、他のRDBMSを使っており、今後のPostgreSQLの利用を検討している方 – PostgreSQLを使っているがパフォーマンス問題に困っている方• 前回の参加者の皆さまからのコメント(アンケートより) – 丁寧な内容で構築・運用時に押さえるべき点を把握できた – 各パラメータについてはある程度知っていたが体系的に学ぶことができた – ツールや分析方法に知らないことが多かった – 全体のアーキテクチャの説明により、チューニングの基本が納得できた• 詳細 – http://bit.ly/MgYKPB Copyright 2012 Uptime Technologies LLC, All rights reserved. 33
    • アップタイム・テクノロジーズについて• オープンソース導入サポートサービスの提供 – 各種OSS(ミドルウェア、ツールなど)についての調査・情報提供 – 設計(基盤~アプリ)、開発の支援 – 機能検証・性能見積もり支援(機能検証、性能検証)、試験設計支援 – OSSコミュニティエスカレーション、等• セミナ、トレーニングの提供 – 「PostgreSQLパフォーマンスチューニング入門」(7/27) – 「LifeKeeper for Linuxで構築・運用する高可用PostgreSQLシステム」• 学習用コンテンツのオンライン販売 – PostgreSQLアーキテクチャ入門(自習用教材) – OSDL DBT-3によるPostgreSQLの性能評価~SATA HDD&SATA SSD編 (技術検 証レポート) 詳細は http://www.uptime.jp をご覧ください。 Copyright 2012 Uptime Technologies LLC, All rights reserved. 34
    • 【お問い合わせ先】アップタイム・テクノロジーズ合同会社永安 悟史E-mail: snaga@uptime.jpWeb: http://www.uptime.jp/ Copyright 2012 Uptime Technologies LLC, All rights reserved. 35