Postico 2 is compatible with PostgreSQL 8.0 or later, Amazon Redshift, CockroachDB, Greenplum, and others. Postico 2 requires macOS 10.15 or later. If you have an older Mac, we also have old versions of Postico available. While Postico 2 is our latest and greatest version of Postico (see whats new in the changelog), we continue to support Postico 1.5. A database app for users Postico 2 is a databa
Postgres Toolkit 0.2をリリースしました
本日、Postgres ToolkitというPostgreSQLのDBA向けツールキットをリリースしました。 http://www.github.com/uptimejp/postgres-toolkit/ https://postgres-toolkit-ja.readthedocs.org/ ■「Postgres Toolkit」とは何か Postgres Toolkitは、PostgreSQLの運用管理を楽にするためのスクリプトやツールのコレクションで、DBA業務の品質や生産性を高めることを目的としたツールキットです。 Postgres Toolkitを使うことで、複雑なSQLを実行したり、自前のスクリプトをメンテする必要性が減少します。コンセプトとしては、「PostgreSQL DBA向けのVictorinox（スイスアーミーナイフ）」のようなイメージです。 もともとは、私がトラブ
PostgreSQLはもはやただのデータベースにあらず ─PostgreSQLカンファレンス2013 基調講演レポート Not so much as a database as a data Platform（単なるデータベースを超えたデータプラットフォームとしての存在） ─11月8日、都内で開催された「PostgreSQLカンファレンス2013」（主催: 日本PostgreSQLユーザ会）の基調講演に登壇したHeroku開発者のピーター・ゲーガン（Peter Geoghegan）氏はPostgreSQLをこう表現しました。 来年には次バージョンのPostgreSQL 9.4のリリースが期待されていますが、ゲーガン氏の言う"データプラットフォーム"としてPostgreSQLはどのような進化を遂げようとしているのでしょうか。本稿ではの基調講演の内容をもとに、PostgreSQLの次なる
本コンテンツは、2014年1月30～31日に筑波大学で開講された「情報システム特別講義D」における講義「Inside PostgreSQL Kernel」の内容を再構成、加筆・修正したものです。 はじめに 本コンテンツについて 本コンテンツへのフィードバックについて アーキテクチャ概要 PostgreSQLの構成要素 PostgreSQLの基本的なアーキテクチャ SQL文の処理される流れ トランザクション管理 トランザクション処理におけるACID特性 各レコードの可視性の管理 Atomicity（原子性）の実装 Consistency（一貫性）の実装 Isolation（分離性）の実装 トランザクション分離レベルの定義 Durability（永続性）の実装 チェックポイント メタデータ管理 pg_controlファイル OID/XID/TID システムカタログ MVCCとストレージ構造 テ
https://mariadb.com/kb/en/optimizer-switch/にあるように、MariaDBのオプティマイザはかなり改良されている。 では、MariaDBのオプティマイザ/エクゼキュータはどの程度優秀か、４つのSELECT文の実行を通してMySQLと(ついでにPostgreSQLと)比較してみる。 (2014.12.3追記：オプティマイザについては省略してますが、こんな本がでます。) 結論を先にいえば「MySQLは検索が速い」というのは都市伝説。MariaDBはがんばってるけどPostgreSQLにはまだまだ及ばず。 ＊念のため。これはベンチマークじゃないよ、オプティマイザ/エクゼキュータの機能比較です。 自分で再確認したい場合はこちらにスクリプト群と実験のやり方を簡単に書いたので参照のこと。 調査環境 同一マシンにMySQL5.6.14、MariaDB10.0.4、
Postgresql9.1+Pacemaker+非同期レプリケーション On Centos6.2 インストール手順
想定課題としては、 ・今までのDBでは、PITRを利用し、データの冗長性を確保していた。そのためマスター障害発生時に切り替え時間がかかっていたのを自動化して短縮したい ・障害発生時のデータロストを最小にする 上記を解決するために今回の変更を実施します。 冗長構成の仕組み 障害発生後は、まず新Slaveを設定して、Replicationを再開させます。その後故障機を修理or交換・原因調査をして、ColdStandby設定を施します。 再びDB2が故障した場合は、DB3がマスターになって、DB1をStandbyに設定することでぐるぐる回っていきます。 この構成の利点は、フェールバック作業が不要なので、停止メンテナンスが要らないことです。 故障したサーバもゆっくり対応・修理が出来、詳細な原因追及やナレッジを作成する余裕ができます。サーバ一台余裕を持つコストより運用負担軽減とサービス向上のメリット
AWSでそこそこセキュアにPostgreSQLインスタンスを立ち上げる
（4/5追記）アクセス管理関連の脆弱性が発見されています。 【リリース情報】セキュリティリリース（9.2.4、9.1.9、9.0.13、8.4.17）が出ています http://pgsqldeepdive.blogspot.jp/2013/04/securityrelease.html バージョン9.2.3、9.1.8、9.0.12、8.4.16およびそれより前のバージョンをお使いの場合はアップグレードしてください。特にクラウド環境で利用する際にはご注意ください。 PostgreSQL Advent Calendar 2012（全部俺）のDay 13です。 クラウドが大流行中です。（個人的に） いろいろ試したり、ちょっとデータを突っ込んで分析したり、といった用途に使う場合には、クラウド上に自分専用のPostgreSQLが動いていると何かと便利です。 PaaSサービスを使うのも良いのですが、
PostgreSQL初期設定これだけは変えておこう
PostgreSQL Advent Calendar 2012（全部俺）のDay 1です。 初日は、まずPostgreSQLを使い始める際の基本的なお作法である初期設定について簡単にまとめてみます。 PostgreSQLは、パラメータの設定を変更せずにデフォルトの設定のまま使い始めても、もちろん動くことは動くのですが、後からいろいろと問題が出てくることもありますし、特に性能関連のパラメータのデフォルト値はあまりに小さく、チューニング云々以前の問題だったりします。 というわけで、私が普段PostgreSQLをインストールして使い始める時、開発機であってもいくつかパラメータを初期設定するようにしています。 使い始める前に設定から入るのは確かに面倒なのですが、最初に設定が必要なパラメータは少数（今回紹介するのは5つ）ですので、まずは最初に必要最低限の設定をしてから使い始めましょう、というのが本エ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
オープンソースカンファレンス2013 広島に参加してきた