令和最新版: PostgreSQLの安全なSET NOT NULL | Wantedly Engineer Blog
データベースのスキーマを変更するときは、スキーマの変更作業によってテーブルが長期間ロックされてしまわないように注意が必要です。 2019年にリリースされたPostgreSQL 12.0以降では、NOT NULLを安全に追加するためによりよいベストプラクティスができています。まだ知らない人もいるかもしれないので、ここで紹介します。 何が問題なのか?次のようなDDLコマンドを考えます。 -- posts.moderatedをNULL禁止にする ALTER TABLE posts ALTER COLUMN moderated SET NOT NULL;これはテーブルをACCESS EXCLUSIVEでロックしたままフルテーブルスキャンを行います。その間は他のトランザクションはこのテーブルに関する処理を進行できません。 テーブルが小さければこれで特に問題ありません。しかし、postsがそれなりに大
Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス
読者対象 ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため，すべての SQL 使用者を対象とする また，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め） 導入 一般的に採用されやすいプライマリキー用の値として，以下を考える。 連番整数 MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ
まだ PostgreSQL の開発で疲弊してるの？ - Qiita
{ "plpgsqlLanguageServer.database": "データベース名", "plpgsqlLanguageServer.user": "ユーザ名", "plpgsqlLanguageServer.password": "パスワード", "plpgsqlLanguageServer.definitionFiles": [ // glob をサポート。 "**/*.sql", "**/*.psql", "**/*.pgsql" ], // Language Server が対応するファイルの拡張子はデフォルトで ['*.pgsql', '*.psql'] です。 // （ SQLite など他の RDS と競合させないためです。） // '*.sql' のファイルも対応させたい場合は、下記の設定を追加してください。 "files.associations": { "*.sq
SmartHR が定期メンテナンスを始めた理由とやめる理由 - SmartHR Tech Blog
SmartHR のソフトウェアエンジニア ぷりんたい です。SmartHR には2017年2月に入社しました。 この記事は SmartHR 長時間のサービス停止を伴うシステムメンテナンスのお知らせ によせて書かれたものです。 ご挨拶 SmartHR では、昨年の6月より週2日という頻度で夜間のサービス停止を行ってきました。まずは、この運用形態を選択したことによりご利用中のお客様にはご不便をおかけしたことをお詫び申し上げます。 今日のクラウドサービスでは、無停止運用が当たり前といった風潮もありますが、なぜ SmartHR が停止メンテナンス運用を選択したのか、今後のサービス提供においてどのようなことを重視していくのかを技術者としての立場からご説明させて頂きます。 SmartHR の開発初期とマルチテナント問題 SmartHR は2015年2月に開発が始まり、同年11月にサービスインしました。
7つのデータベース 7つの世界 2章 PostgreSQL 2日目 - Qiita
INSERT INTO venues(name, postal_code, country_code) VALUES ('My Place', '97205', 'us'); INSERT INTO events (title, starts, ends, venue_id) VALUES ('Moby', '2012-02-06 21:00:00', '2012-02-06 23:00:00', ( SELECT venue_id FROM venues WHERE name = 'Crystal Ballroom' ) ); INSERT INTO events (title, starts, ends, venue_id) VALUES ('Wedding', '2012-02-26 21:00:00', '2012-02-26 23:00:00', 2), ('Dinner wit
現在実行中のSQLクエリを殺す流れ - Qiita
SQLでめちゃくちゃ時間がかかるクエリが走ってしまっていて問題が起こっている場合にとるべき対処。 本来は、問い合わせを行っているWebサーバー側で対応できれば良いが、DBサーバー側で対応の必要がある時。 1. pg_stat_activityを見る 現在実行中のクエリはpg_stat_activityテーブルが管理している 参考： http://www.postgresql.org/docs/9.4/static/monitoring-stats.html#PG-STAT-ACTIVITY-VIEW http://lets.postgresql.jp/documents/technical/statistics/3 pg_stat_activityの中でも大事なのが、以下のフィールド pid: プロセスのID。殺す時に指定する。 query_start: SQLクエリを実行し始めた時間。
[翻訳] たった一つの設定変更が如何にしてクエリのパフォーマンスを50倍も改善したか （How a single PostgreSQL config change improved slow query performance by 50x）
先日、「How a single PostgreSQL config change improved slow query performance by 50x」というPostgreSQLのSSD環境でのチューニングの記事を見つけたのですが、これをTweetしたらRTやLikeを比較的たくさん頂きました。 How a single PostgreSQL config change improved slow query performance by 50x https://amplitude.engineering/how-a-single-postgresql-config-change-improved-slow-query-performance-by-50x-85593b8991b0 How a single PostgreSQL config change improved sl
GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickey
果たしてGitLab.comで何が起きたのでしょうか？ これまでの経緯をまとめました。 スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。 これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時（世界協定時。日本時間2月1日午前8時）、YP氏（Yorick Peterse氏と思われる）はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時
CentOS で PostgreSQL を使ってみよう！(3) — Let's Postgres
Appendix A: PostgreSQL のログ デフォルトでは、データベースクラスタの「pg_log」というディレクトリに、起動した日の曜日名のついたファイルを作ってログを書き込んでいます。 [root @server1 ~]# ls /var/lib/pgsql/data/pg_log/ postgresql-Tue.log しかし、「そのログがいつ記録されたか」という必須情報が、デフォルトの設定では出力されません。デフォルトでは、たとえば存在しないテーブルを参照する "SELECT * FROM abc;" という SQL を実行すると、エラーになりますが、 ERROR: relation "abc" does not exist というような形で記録され、エラー発生日時を確認できません。これを、記録日時が確認できるように設定してみましょう。 ★ 例：ログ記録日時の出力を設定する
( 久々にブログw)CentOS7にpostgresqlを導入し$PGDATAを変更した時の - いわなが まさひろ の メモ帳
CentOS7にpostgresqlを導入してみた。 データディレクトリー($PGDATA?)をデフォルトから変更するときに少しはまったのでメモです。 yum install postgresql-server でpostgresql 9.2 を導入。 postgres ユーザーで initdb を実施。 このとき -D オプションで任意のディレクトリー(/pgsql/data)を指定。 この後、 systemctl start postgresql.service を実行すると、 postgresql-check-db-dir: "/var/lib/pgsql/data" is missing or empty. が表示される。 /usr/lib/systemd/system/postgresql.service 内の "Environment=PGDATA=" のディレクトリーを in
PostgreSQL9.3でのストリーミングレプリケーション環境の構築 - Qiita
はじめに PostgreSQLのレプリケーションは、WEBに情報があるが、実際に構築した際には、細かい手順が省かれていたり少しハマったので、ここに簡単にまとめておく。 レプリケーションしたDBへの、クエリ分散にはpgpool-IIを利用したため、それについては別記事で書く予定。 前提知識 ストリーミングレプリケーション環境を構築する上で、一応知っておいたほうがいいこと。 レプリケーションの仕組み マスタDBで発生したWALファイルを、スレーブとなるDBに反映させることで、レプリケーションを実現している。 レプリケーションの同期モード こちらの記事がわかりやすい。 http://codezine.jp/article/detail/7109 同期・メモリ同期は、スレーブが１台の場合はスレーブに障害が発生すると、マスタへの更新も行われず、全体の障害につながってしまうので注意。 今回試した環境
PostgreSQL9.4でストリーミングレプリケーションする - マコーの日記
概要 PostgreSQL9.4でストリーミングレプリケーションの構成を組んでみる 以下のような構成を作成する マスター1台 スレーブ2台 マスターからスレーブに矢印を引いたところに「同期」と「非同期」とあるが、これはWALファイルをマスターからスレーブに転送した時にスレーブに書き込まれてからレスポンスを返す設定とスレーブに書き込まれたかどうか確認せずに即レスポンスを返す設定のことである。 スレーブが複数台ある場合は、全て非同期か、1台のみ同期でそれ以外が非同期しか設定が出来ない仕様になっている。 また、単純なレプリケーションの設定のみではなく以下の設定も記述する マスターが落ちた時のスレーブをマスターに昇格させる設定 落ちたノードに対してリカバリするためにWALアーカイブの設定 環境 AWS EC2インスタンス上に以下のバージョンの環境を構築する。 CentOS 7 PostgreSQL
PostgreSQLでWebサービスを運用するためにやっていること - LCL 開発者ブログ
弊社では、RDBMSにPostgreSQLを利用して数年間サービスを運営しています。 PostgreSQLはMySQLと違って、Webサービスでの運用事例をあまり見かけないので、今回は弊社サービスの「夜行バス比較なび 」でどのように運用しているかを紹介いたします。 システムの特徴 ユーザからのアクセスは、9割が参照処理。 データはバッチ処理で、随時 ( 毎分 ) 更新されている。 参照SQLの結果はmemcachedを利用してキャッシュをしているが、データの更新頻度が高いため長時間のキャッシュはしていない。 参照SQLは、集計処理が多いため比較的重いSQL。 参照対象となるテーブルのデータ量は、最大で数100万レコードと比較的少ない。 24/7で稼働。 構成 AWSのEC2上に、PostgreSQL 9.3を導入しています。c4系のインスタンスを使いたいので、RDSは使っていません。インス
PostgresのRDSチューニング - Qiita
Wantedlyは今までRDSを初期設定のまま使っていました。ごめんなさい。 今回ちゃんとチューニングしてみたのでやってみた過程と結果を書きます。 ちなみにWantedlyはDBを幾つか持っていて、その中のDBの一つの最適化結果です。 NewRelic での測定の結果、平均31ms ぐらいかかっていたのが、 平均23ms ぐらいになっているので25％ぐらいの改善になりました。 インスタンスタイプ 使っているDBのインスタンスタイプです モデル: r3.4xlarge vCPU: 16 メモリ: 122GB SSDストレージ: 1 x 320G デフォルト値 RDSはパラメータグループを調節します。 それぞれのデフォルト値は書かれてないですが、以下のSQL出だすことができます。 => SELECT name,setting,unit FROM pg_settings; name | sett
PostgreSQLでCOPYする時はインデックスを削除すべし、数十倍高速化する -- ぺけみさお
常識なのかも知れないが、タイトルの通りである。 先日、拙作のGemのランキングサイトBestGems.orgの1億レコードほどあるデータベースをSQLite3からPostgreSQLへマイグレーションした。 この際に単にPostgreSQLのCOPY文を使うだけでは速度が遅すぎる問題が発生したため、このエントリを書く。 PostgreSQLに大量のデータを投入する方法については、PostgreSQLの公式ドキュメントが最も信頼のおける情報源だ。ちゃんと日本語訳されているので、これを読まないという選択肢はないだろう。ドキュメントによると、以下のアプローチがある。 自動コミットをオフにするCOPYの使用インデックスを削除する外部キー制約の削除maintenance_work_memを増やすcheckpoint_segmentsを増やすWALアーカイブ処理とストリーミングレプリケーションの無効化
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - simon-engledew/gocmdpev: A command-line GO Postgres query visualizer, heavily inspired by pev (https://github.com/AlexTatiyants/pev)
PostgreSQL ROW_NUMBER() Explained with Practical Examples
タイトル1
PostgreSQL 9.5 によるレプリケーション構成（同期） - Qiita
Rebuild PostgreSQL data directory