Submit Search
Upload
PostgreSQL DBのバックアップを一元化しよう
•
4 likes
•
3,403 views
Yukiya Hayashi
Follow
PostgreSQL Conference Japan 2017での発表資料です。
Read less
Read more
Engineering
Report
Share
Report
Share
1 of 56
Download now
Download to read offline
Recommended
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
NTT DATA Technology & Innovation
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
Hironobu Suzuki
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
NTT DATA Technology & Innovation
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
NTT DATA Technology & Innovation
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
NTT DATA Technology & Innovation
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
NTT DATA Technology & Innovation
PostgreSQLレプリケーション徹底紹介
PostgreSQLレプリケーション徹底紹介
NTT DATA OSS Professional Services
Vacuum徹底解説
Vacuum徹底解説
Masahiko Sawada
Recommended
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
PostgreSQL13でのレプリケーション関連の改善について(第14回PostgreSQLアンカンファレンス@オンライン)
NTT DATA Technology & Innovation
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
PostgreSQLのリカバリ超入門(もしくはWAL、CHECKPOINT、オンラインバックアップの仕組み)
Hironobu Suzuki
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
NTT DATA Technology & Innovation
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
PostgreSQLのロール管理とその注意点(Open Source Conference 2022 Online/Osaka 発表資料)
NTT DATA Technology & Innovation
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
スケールアウトするPostgreSQLを目指して!その第一歩!(NTTデータ テクノロジーカンファレンス 2020 発表資料)
NTT DATA Technology & Innovation
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
NTT DATA Technology & Innovation
PostgreSQLレプリケーション徹底紹介
PostgreSQLレプリケーション徹底紹介
NTT DATA OSS Professional Services
Vacuum徹底解説
Vacuum徹底解説
Masahiko Sawada
レプリケーション遅延の監視について(第40回PostgreSQLアンカンファレンス@オンライン 発表資料)
レプリケーション遅延の監視について(第40回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界
Yoshinori Nakanishi
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
Masahiko Sawada
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
NTT DATA Technology & Innovation
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
NTT DATA Technology & Innovation
HA環境構築のベスト・プラクティス
HA環境構築のベスト・プラクティス
EnterpriseDB
PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報
Masahiko Sawada
障害とオペミスに備える! ~Oracle Databaseのバックアップを考えよう~
障害とオペミスに備える! ~Oracle Databaseのバックアップを考えよう~
Shinnosuke Akita
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
NTT DATA Technology & Innovation
大規模データ活用向けストレージレイヤソフトのこれまでとこれから(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
大規模データ活用向けストレージレイヤソフトのこれまでとこれから(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
NTT DATA Technology & Innovation
Pacemaker + PostgreSQL レプリケーション構成(PG-REX)のフェイルオーバー高速化
Pacemaker + PostgreSQL レプリケーション構成(PG-REX)のフェイルオーバー高速化
kazuhcurry
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
NTT DATA Technology & Innovation
PostgreSQL: XID周回問題に潜む別の問題
PostgreSQL: XID周回問題に潜む別の問題
NTT DATA OSS Professional Services
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
KafkaとPulsar
KafkaとPulsar
Yahoo!デベロッパーネットワーク
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
歩 柴田
コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話
Yuta Shimada
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
[db tech showcase Tokyo 2015] C27:楽天MySQL Backup Structure by 楽天株式会社 粟田啓介
[db tech showcase Tokyo 2015] C27:楽天MySQL Backup Structure by 楽天株式会社 粟田啓介
Insight Technology, Inc.
Amazon Aurora Deep Dive (db tech showcase 2016)
Amazon Aurora Deep Dive (db tech showcase 2016)
Amazon Web Services Japan
More Related Content
What's hot
レプリケーション遅延の監視について(第40回PostgreSQLアンカンファレンス@オンライン 発表資料)
レプリケーション遅延の監視について(第40回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界
Yoshinori Nakanishi
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
Masahiko Sawada
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
NTT DATA Technology & Innovation
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
NTT DATA Technology & Innovation
HA環境構築のベスト・プラクティス
HA環境構築のベスト・プラクティス
EnterpriseDB
PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報
Masahiko Sawada
障害とオペミスに備える! ~Oracle Databaseのバックアップを考えよう~
障害とオペミスに備える! ~Oracle Databaseのバックアップを考えよう~
Shinnosuke Akita
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
NTT DATA Technology & Innovation
大規模データ活用向けストレージレイヤソフトのこれまでとこれから(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
大規模データ活用向けストレージレイヤソフトのこれまでとこれから(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
NTT DATA Technology & Innovation
Pacemaker + PostgreSQL レプリケーション構成(PG-REX)のフェイルオーバー高速化
Pacemaker + PostgreSQL レプリケーション構成(PG-REX)のフェイルオーバー高速化
kazuhcurry
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
NTT DATA Technology & Innovation
PostgreSQL: XID周回問題に潜む別の問題
PostgreSQL: XID周回問題に潜む別の問題
NTT DATA OSS Professional Services
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
KafkaとPulsar
KafkaとPulsar
Yahoo!デベロッパーネットワーク
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
歩 柴田
コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話
Yuta Shimada
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
What's hot
(20)
レプリケーション遅延の監視について(第40回PostgreSQLアンカンファレンス@オンライン 発表資料)
レプリケーション遅延の監視について(第40回PostgreSQLアンカンファレンス@オンライン 発表資料)
あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
PostgreSQLレプリケーション10周年!徹底紹介!(PostgreSQL Conference Japan 2019講演資料)
HA環境構築のベスト・プラクティス
HA環境構築のベスト・プラクティス
PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLの統計情報について(第26回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報
障害とオペミスに備える! ~Oracle Databaseのバックアップを考えよう~
障害とオペミスに備える! ~Oracle Databaseのバックアップを考えよう~
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
押さえておきたい、PostgreSQL 13 の新機能!! (PostgreSQL Conference Japan 2020講演資料)
大規模データ活用向けストレージレイヤソフトのこれまでとこれから(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
大規模データ活用向けストレージレイヤソフトのこれまでとこれから(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019/09/05)
Pacemaker + PostgreSQL レプリケーション構成(PG-REX)のフェイルオーバー高速化
Pacemaker + PostgreSQL レプリケーション構成(PG-REX)のフェイルオーバー高速化
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQL: XID周回問題に潜む別の問題
PostgreSQL: XID周回問題に潜む別の問題
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLのfull_page_writesについて(第24回PostgreSQLアンカンファレンス@オンライン 発表資料)
KafkaとPulsar
KafkaとPulsar
iostat await svctm の 見かた、考え方
iostat await svctm の 見かた、考え方
コンテナにおけるパフォーマンス調査でハマった話
コンテナにおけるパフォーマンス調査でハマった話
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL14の pg_stat_statements 改善(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
Similar to PostgreSQL DBのバックアップを一元化しよう
[db tech showcase Tokyo 2015] C27:楽天MySQL Backup Structure by 楽天株式会社 粟田啓介
[db tech showcase Tokyo 2015] C27:楽天MySQL Backup Structure by 楽天株式会社 粟田啓介
Insight Technology, Inc.
Amazon Aurora Deep Dive (db tech showcase 2016)
Amazon Aurora Deep Dive (db tech showcase 2016)
Amazon Web Services Japan
Mysql casial01
Mysql casial01
matsuo kenji
オンプレのDbaがazureのデータベースを使ってみた
オンプレのDbaがazureのデータベースを使ってみた
Masayuki Ozawa
baserCMSのキャッシュの仕組み~もうキャッシュでハマらない!!~【勉強会資料】
baserCMSのキャッシュの仕組み~もうキャッシュでハマらない!!~【勉強会資料】
株式会社キャッチアップ
Web App for Containers + MySQLでコンテナ対応したPHPアプリを作ろう!
Web App for Containers + MySQLでコンテナ対応したPHPアプリを作ろう!
Yoichi Kawasaki
[db tech showcase Tokyo 2017] B14: 4年連続No.1リーダー評価のストレージでDBクローンするとどんな感じ?瞬時のクロー...
[db tech showcase Tokyo 2017] B14: 4年連続No.1リーダー評価のストレージでDBクローンするとどんな感じ?瞬時のクロー...
Insight Technology, Inc.
PostgreSQLアーキテクチャ入門(PostgreSQL Conference 2012)
PostgreSQLアーキテクチャ入門(PostgreSQL Conference 2012)
Uptime Technologies LLC (JP)
カジュアルにバックアップ - MySQL Casual Talks 福岡
カジュアルにバックアップ - MySQL Casual Talks 福岡
Aya Komuro
[db tech showcase Tokyo 2015] A33:Amazon Aurora Deep Dive by アマゾン データ サービス ジャ...
[db tech showcase Tokyo 2015] A33:Amazon Aurora Deep Dive by アマゾン データ サービス ジャ...
Insight Technology, Inc.
MySQLバックアップの基本
MySQLバックアップの基本
yoyamasaki
Rakuten New MySQL Backup System With Xtrabackup
Rakuten New MySQL Backup System With Xtrabackup
Rakuten Group, Inc.
MySQLメインの人がPostgreSQLのベンチマークをしてみた話
MySQLメインの人がPostgreSQLのベンチマークをしてみた話
hiroi10
ioMemoryとAtomic Writeによるデータベース高速化
ioMemoryとAtomic Writeによるデータベース高速化
IIJ
Aurora
Aurora
maruyama097
PHPで大規模ブラウザゲームを開発してわかったこと
PHPで大規模ブラウザゲームを開発してわかったこと
Kentaro Matsui
プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009
プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009
Ryota Watabe
AWSのデータベースサービス全体像
AWSのデータベースサービス全体像
Amazon Web Services Japan
AWSを使ってWordPressの簡単・便利・高速Backup術
AWSを使ってWordPressの簡単・便利・高速Backup術
Takayuki Niinuma
バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い
バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い
Ryota Watabe
Similar to PostgreSQL DBのバックアップを一元化しよう
(20)
[db tech showcase Tokyo 2015] C27:楽天MySQL Backup Structure by 楽天株式会社 粟田啓介
[db tech showcase Tokyo 2015] C27:楽天MySQL Backup Structure by 楽天株式会社 粟田啓介
Amazon Aurora Deep Dive (db tech showcase 2016)
Amazon Aurora Deep Dive (db tech showcase 2016)
Mysql casial01
Mysql casial01
オンプレのDbaがazureのデータベースを使ってみた
オンプレのDbaがazureのデータベースを使ってみた
baserCMSのキャッシュの仕組み~もうキャッシュでハマらない!!~【勉強会資料】
baserCMSのキャッシュの仕組み~もうキャッシュでハマらない!!~【勉強会資料】
Web App for Containers + MySQLでコンテナ対応したPHPアプリを作ろう!
Web App for Containers + MySQLでコンテナ対応したPHPアプリを作ろう!
[db tech showcase Tokyo 2017] B14: 4年連続No.1リーダー評価のストレージでDBクローンするとどんな感じ?瞬時のクロー...
[db tech showcase Tokyo 2017] B14: 4年連続No.1リーダー評価のストレージでDBクローンするとどんな感じ?瞬時のクロー...
PostgreSQLアーキテクチャ入門(PostgreSQL Conference 2012)
PostgreSQLアーキテクチャ入門(PostgreSQL Conference 2012)
カジュアルにバックアップ - MySQL Casual Talks 福岡
カジュアルにバックアップ - MySQL Casual Talks 福岡
[db tech showcase Tokyo 2015] A33:Amazon Aurora Deep Dive by アマゾン データ サービス ジャ...
[db tech showcase Tokyo 2015] A33:Amazon Aurora Deep Dive by アマゾン データ サービス ジャ...
MySQLバックアップの基本
MySQLバックアップの基本
Rakuten New MySQL Backup System With Xtrabackup
Rakuten New MySQL Backup System With Xtrabackup
MySQLメインの人がPostgreSQLのベンチマークをしてみた話
MySQLメインの人がPostgreSQLのベンチマークをしてみた話
ioMemoryとAtomic Writeによるデータベース高速化
ioMemoryとAtomic Writeによるデータベース高速化
Aurora
Aurora
PHPで大規模ブラウザゲームを開発してわかったこと
PHPで大規模ブラウザゲームを開発してわかったこと
プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009
プロとしてのOracleアーキテクチャ入門 ~番外編~ @ Developers Summit 2009
AWSのデータベースサービス全体像
AWSのデータベースサービス全体像
AWSを使ってWordPressの簡単・便利・高速Backup術
AWSを使ってWordPressの簡単・便利・高速Backup術
バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い
バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い
More from Yukiya Hayashi
I have a problem when operating AWS with multiple accounts
I have a problem when operating AWS with multiple accounts
Yukiya Hayashi
My misstake on Ansible’s lineinfile module
My misstake on Ansible’s lineinfile module
Yukiya Hayashi
AWS SSO x On-Prem AD Easy IAM user management on Jtf2021
AWS SSO x On-Prem AD Easy IAM user management on Jtf2021
Yukiya Hayashi
AWS Cognito makes old web apps available from anywhere
AWS Cognito makes old web apps available from anywhere
Yukiya Hayashi
アドベントカレンダー から学ぶOCIの空気感
アドベントカレンダー から学ぶOCIの空気感
Yukiya Hayashi
オンボーディングを楽しむ
オンボーディングを楽しむ
Yukiya Hayashi
事前アンケート集計 Terraform meetup tokyo#2
事前アンケート集計 Terraform meetup tokyo#2
Yukiya Hayashi
I want the power of onboarding!
I want the power of onboarding!
Yukiya Hayashi
How did you start learning Azure
How did you start learning Azure
Yukiya Hayashi
My feelings of going to the first conference overseas
My feelings of going to the first conference overseas
Yukiya Hayashi
Let's split text by awk command
Let's split text by awk command
Yukiya Hayashi
What i feel when began use AWS CodePipeline as GitLab Ci user
What i feel when began use AWS CodePipeline as GitLab Ci user
Yukiya Hayashi
How to get rid of terraform plan diffs
How to get rid of terraform plan diffs
Yukiya Hayashi
Task and Time monitoring with Backlog and Toggl
Task and Time monitoring with Backlog and Toggl
Yukiya Hayashi
Oiradaichi's Akamai Journey
Oiradaichi's Akamai Journey
Yukiya Hayashi
What does the monitoring tool use at oisix ra daichi?
What does the monitoring tool use at oisix ra daichi?
Yukiya Hayashi
We love backlog ! in reCap event.
We love backlog ! in reCap event.
Yukiya Hayashi
What we expect of neo4j
What we expect of neo4j
Yukiya Hayashi
Backlog World 2019 LT - We love backlog !
Backlog World 2019 LT - We love backlog !
Yukiya Hayashi
20190116 neo4jug-lt
20190116 neo4jug-lt
Yukiya Hayashi
More from Yukiya Hayashi
(20)
I have a problem when operating AWS with multiple accounts
I have a problem when operating AWS with multiple accounts
My misstake on Ansible’s lineinfile module
My misstake on Ansible’s lineinfile module
AWS SSO x On-Prem AD Easy IAM user management on Jtf2021
AWS SSO x On-Prem AD Easy IAM user management on Jtf2021
AWS Cognito makes old web apps available from anywhere
AWS Cognito makes old web apps available from anywhere
アドベントカレンダー から学ぶOCIの空気感
アドベントカレンダー から学ぶOCIの空気感
オンボーディングを楽しむ
オンボーディングを楽しむ
事前アンケート集計 Terraform meetup tokyo#2
事前アンケート集計 Terraform meetup tokyo#2
I want the power of onboarding!
I want the power of onboarding!
How did you start learning Azure
How did you start learning Azure
My feelings of going to the first conference overseas
My feelings of going to the first conference overseas
Let's split text by awk command
Let's split text by awk command
What i feel when began use AWS CodePipeline as GitLab Ci user
What i feel when began use AWS CodePipeline as GitLab Ci user
How to get rid of terraform plan diffs
How to get rid of terraform plan diffs
Task and Time monitoring with Backlog and Toggl
Task and Time monitoring with Backlog and Toggl
Oiradaichi's Akamai Journey
Oiradaichi's Akamai Journey
What does the monitoring tool use at oisix ra daichi?
What does the monitoring tool use at oisix ra daichi?
We love backlog ! in reCap event.
We love backlog ! in reCap event.
What we expect of neo4j
What we expect of neo4j
Backlog World 2019 LT - We love backlog !
Backlog World 2019 LT - We love backlog !
20190116 neo4jug-lt
20190116 neo4jug-lt
PostgreSQL DBのバックアップを一元化しよう
1.
DBのバックアップを一元化しよう ~BaRManによる”スタイリッシュ”バックアップのススメ~ 林 如弥 (はやし ゆきや) @morihaya55 CC0
https://pixabay.com/en/restaurant-bar-stools-lights-2618315/ PostgreSQL PostgreSQL Conference Japan 2017
2.
アジェンダ • 本セッションのゴール • バックアップについておさらい •
BaRMan導入前 • 何故BaRManを選択したか • BaRMan導入後 • 運用していて注意するところ • BaRMan導入方法 • まとめ
3.
本セッションのゴール • BaRManというツールの魅力を知って頂く – どんな機能があり –
どう運用が楽になるのか – もちろんデメリット(注意点)もあるよ BaRMan - Backup and Recovery Manager
4.
バックアップについておさらい はじめに
5.
バックアップについておさらい • 論理バックアップ – >
pg_dumpやpg_dumpallでSQLファイル保存 • 物理バックアップ – オフライン・バックアップ -> DBを停止した状態で$PGDATAをバックアップ – オンライン・バックアップ -> DBを起動した状態で$PGDATAとWALログをバックアッ プ [Let‘s Postgres](https://lets.postgresql.jp/documents/technical/backup/1)
6.
バックアップについておさらい • 論理バックアップ – >規模が大きいとバックアップもリストアも時間が かかる •
物理バックアップ – オフライン・バックアップ -> DBを停止しなくてはならない – オンライン・バックアップ -> 手順がちょっと複雑。PITRができる。(アーカイブ出力 設定、取得時のpg_start_backup()実行 ※v9.1からは pg_basebackupで簡単に)
7.
バックアップについておさらい • 論理バックアップ – >難易度:簡単 •
物理バックアップ – オフライン・バックアップ -> 難易度:簡単 – オンライン・バックアップ -> 難易度:ちょっと難しい
8.
バックアップについておさらい • 論理バックアップ – RPO:バックアップ取得時 –
RTO:データ量に比例して長くなる • 物理バックアップ – オフライン・バックアップ • RPO:バックアップ取得時 • RTO:仕組み次第で一瞬(ローカルに2世代持つ等) – オンライン・バックアップ • RPO:直近。WALファイルでロールフォワード • RTO:データ量に比例して長くなる
9.
バックアップについておさらい 本番用途のDBの場合、RPOを重視して物理オ ンライン・バックアップを採用するのが一般的(と 思います) ※BaRManで行うのも物理オンライン・バック アップです
10.
BaRMan導入前
11.
BaRMan導入前 環境、サーバによって異なるバック アップ方式が混在していた
12.
BaRMan導入前 パターンA 手動定期作業としてpg_dumpで週次で論理 バックアップを取得し、ダンプ集積用のサーバ へ保管 DB BK SQL pg_dump
13.
BaRMan導入前 パターンB cronで独自シェルで以下を取得 ・日次でオンラインバックアップ ・30分単位でwalアーカイブ コールドスタンバイDBサーバと、ダンプ集積用 のサーバへ保管 DB BK rsync WAL Cold-Std-DB WAL rsync rsync rsync WAL $PGDATA $PGDATA
$PGDATA
14.
BaRMan導入前 パターンC cronでpg_rmanを使用し以下を取得 ・日次でFullバックアップ ・30分単位でArchバックアップ DB WAL Hot-Std-DB $PGDATA SR WAL $PGDATA pg_rman
15.
BaRMan導入前 パターンD 不定期で取得した 物理オフラインバックアップが散在 DB BK $PGDATA rsync $PGDATA _bk1 $PGDATA _bk2 cp -Rp ※オンライン・バックアップと見分けがつかないorz
16.
BaRMan導入前 用途に合わせた柔軟なバックアップと いえば聞こえが良いけど、管理者とし ては「このDBの場合は、このバック アップ方法」という状態は嬉しくない そんな課題を抱えていましたが….
17.
https://unsplash.com/photos/cjOWoz4iq7k
18.
BaRMan導入のチャンス到来 サーバ筐体の保守期限切れが近づき、 リプレースが必要になった(IT式年遷宮) もろもろ見直す! ・バックアップツールにBaRMan ・PostgreSQL 8系 ->
9.5へVUP ・PG-REX構成(SRでHot standby) https://unsplash.com/photos/cjOWoz4iq7k
19.
何故BaRManを選択したか ばーまん→
20.
何故BaRManを選択したか • 複数DBのリモートバックアップ • pgコマンドによるSR+ベースバックアップ •
バックアップカタログ • 世代管理(リテンションポリシー) • Pythonで書かれている
21.
何故BaRManを選択したか • 複数DBのリモートバックアップ – >
一元管理したい • pgコマンドによるSR+ベースバックアップ – > SRの設定だけすれば良い。OS意識しない • バックアップカタログ – > どのベースから、どこまでリストアするか • 世代管理(リテンションポリシー) – > “find -mtime +180 | xargs rm” はもう嫌だ • Pythonで書かれている – > いざとなったら読める
22.
何故BaRManを選択したか 他の方法も検討したが、”複数DBをリ モートで管理”できるBaRManにした • 自分で開発 ->
車輪の再発明ツライ • pg_rman -> 単体DB用。リモートできない (NFSとかはできれば避けたい…) • wal-e -> 単体DB用。GitHubスター2K超とダ ントツ。クラウド時代のツールな印象
23.
BaRMan導入後 ばーまん→
24.
DB BaRMan導入後 BK Hot-Std-DB SR DB Hot-Std-DB SR DB Hot-Std-DB SR DB
Hot-Std-DB SR BaRMan Pacemaker/Corosync Pacemaker/Corosync Pacemaker/CorosyncPacemaker/Corosync DB SR SR
25.
BaRMan導入後 全てのDBのバックアップデータは、 BaRManによってBKサーバへ集約される ー>「このDBのバックアップデータ、ローカ ルだっけ?リモートだっけ?」問題の解消
26.
BaRMan導入後 全てのDBからBKサーバへSR(ストリーミン グ・レプリケーション)で更新データ(wal)を 常に送信 さらにPostgreSQL 9.4からのレプリケーショ ンスロットを利用 ー>「walの管理めんどい」問題の解消
27.
BaRMan導入後 動作としてはBaRManから ”pg_receivexlog”コマンドを利用して常に walを受信 # ps auxf
※一部省略 barman … /usr/bin/python /usr/bin/barman -c /etc/barman.conf -q receive-wal db009-6535 barman … ¥_ /usr/local/postgres/bin/pg_receivexlog -- dbname=dbname=replication host=db009 port=6535 replication=true user=postgres application_name=barman_receive_wal -
28.
BaRMan導入後 DBから見るとBaRManはSRのスタンバイDB に見える # ps auxf
※一部省略 postgres … postgres: wal sender process postgres 192.168.11.12(41372) streaming 1/92A23BC0 postgres=# SELECT * FROM pg_stat_replication; ※一部省略 -[ RECORD 1 ]----+------------------------------ pid | 12518 usesysid | 10 usename | postgres application_name | barman_receive_wal client_addr | 192.168.11.12 state | streaming sync_state | async
29.
BaRMan導入後 レプリケーションスロットを利用することで、 無駄の無いwalローテーションが行われる postgres=# select *
from pg_replication_slots; -[ RECORD 1 ]+----------- slot_name | barman plugin | slot_type | physical datoid | database | active | t active_pid | 12521 xmin | catalog_xmin | restart_lsn | 1/92000000
30.
BaRMan導入後 バックアップのカタログ機能で複数サーバ の取得状況を確認できる # barman list-backup
all ※一部省略 db003-5432 20171025...- Size: 1.1 GiB - WAL Size: 688.0 MiB db003-5432 20171018...- Size: 984.2 MiB - WAL Size: 1.7 GiB db004-5432 20171025...- Size: 98.2 MiB - WAL Size: 0 B db004-5432 20171018...- Size: 108.5 MiB - WAL Size: 48.0 MiB db005-5432 20171025...- Size: 339.3 MiB - WAL Size: 0 B -> 「このDBのバックアップいつ取得し た?」問題の解消
31.
BaRMan導入後 ベースバックアップの取得は内部的 に”pg_basebackup”を利用するため、 PostgreSQLのプロトコルだけで完結する。 「DBがコンテナ/Windows上だから ssh/rsyncできない」問題の解消 ※リストアは別のお話…
32.
運用していて注意するところ 良いことばかり じゃない!
33.
https://unsplash.com/photos/0zBJmvRpYMM
34.
BaRManサーバがボトルネックになる • ディスク容量 • ネットワーク帯域 •
バックアップデータの可用性 https://unsplash.com/photos/0zBJmvRpYMM
35.
BaRManサーバがボトルネックになる • ディスク容量 –> DB数×保存世代数+各DBのWAL •
ネットワーク帯域 –> 複数DBを並列リストアするには辛い • バックアップデータの可用性 –> バックアップデータのバックアップ? https://unsplash.com/photos/0zBJmvRpYMM
36.
BaRManサーバがボトルネックになる 【対策】 rsyncで待機サーバにBaRMan管理 ディレクトリを定期コピーし、可用性向上と 2並列でのリストアを可能とした https://unsplash.com/photos/0zBJmvRpYMM BK BaRMan $barman _home BK_2 $barman _home rsync BaRMan SR ※超大規模環境のグループ化して分散するなどの方法を考える必要がありそう
37.
DBのF/O後のフォローが必要 PG-REX構成でF/Oした場合、以下のフォ ロー作業が必要 1. F/O後のDBへスロット作成 2. ベースバックアップ取得 3.
旧プライマリDBのスロット削除 ※さらにF/B後も同じ作業が必要
38.
DBのF/O後のフォローが必要 1. 正常時 DB Hot-Std-DB SR Pacemaker/Corosync BK BaRMan SR 2.
障害->マスタDBの切り替わり DB DB(NEW!) Pacemaker/Corosync BK BaRMan
39.
DBのF/O後のフォローが必要 3. 旧マスタの障害復旧 DB DB(NEW!) Pacemaker/Corosync BK BaRMan 4.
SR再構成 Hot-Std-DB DB(NEW!) Pacemaker/Corosync BK BaRMan SR
40.
DBのF/O後のフォローが必要 5. BaRMan用レプリケーションスロット作成 6. ベースバックアップ再取得&walストリーム Hot-Std-DB
DB(NEW!) Pacemaker/Corosync BK BaRMan SR Hot-Std-DB DB(NEW!) Pacemaker/Corosync BK BaRMan SR receive-wal --create-slot SR
41.
DBのF/O後のフォローが必要 7. 新マスタ側のレプリケーションスロット削除 Hot-Std-DB DB(NEW!) Pacemaker/Corosync BK BaRMan SR SR 削除 この未使用になったスロットの削除を行わないと、walが 削除されない
-> ディスクが溢れるコンボが発動する
42.
DBのF/O後のフォローが必要 【対策】監視ツールでpg_replication_slotsの active列を定期監視 postgres=# select *
from pg_replication_slots; -[ RECORD 1 ]+----------- slot_name | barman plugin | slot_type | physical datoid | database | active | t active_pid | 12521 xmin | catalog_xmin | restart_lsn | 1/92000000 active = t でなければ警告を上げる
43.
bandwidth_limitオプション ドキュメントにpg_basebackupを使用する場合は 帯域制限サポートしないとあるが、効く。 PostgreSQL 9.4から”-r rate”オプションが追加。 http://docs.pgbarman.org/release/2.3/ “not
supported”
44.
bandwidth_limitオプション ソース上ではちゃんと対応している https://github.com/2ndquadrant-it/barman/blob/master/barman/backup_executor.py
45.
bandwidth_limitオプション しかしリストア時に変に効いた 例:100GBデータのリカバリ時間 + bandwidth_limit=3000 ->
12時間 + bandwidth_limit=0 -> 1時間 BaRManというより、内部的に呼ばれるrsyncが 悪さをしていそう…(?) ※あくまで個人事例ですのでご参考程度に 他要因の可能性があります
46.
bandwidth_limitオプション 【対策】リストアする場合、定義を bandwidth_limit=0に変更してから ”barman recover”を実行する (手動運用でカバー)
47.
BaRMan導入方法 ばーまん→
48.
BaRMan導入方法 インストール方法は極めて簡単 • PIP ※OSパッケージ依存しないのでオススメ •
RHEL7, RHEL6 and RHEL5 (CentOSも) • Debian and Ubuntu yum install barman ※EPELとPGDGレポジトリが必要 apt-get install barman ※PGDGレポジトリが必要 export PATH=/xxxx/postgres/bin/:$PATH pip install barman http://docs.pgbarman.org/release/2.3/#installation
49.
BaRMan導入方法 設定もシンプル • 全体設定(/etc/barman.conf) [barman] barman_user =
barman configuration_files_directory = /etc/barman.d barman_home = /var/backup/barman log_file = /var/log/barman/barman.log log_level = INFO bandwidth_limit = 0
50.
BaRMan導入方法 設定もシンプル • サーバ単位設定(/etc/barman.d/xxx.conf) [db001.slave-5432] description =
"db001.slave port 5432 (Streaming-Only)" conninfo = host=db001.slave user=barman dbname=postgres port=5432 streaming_conninfo = host=db001.slave user=barman port=5432 backup_method = postgres streaming_backup_name = barman_streaming_backup streaming_archiver = on slot_name = barman_slot path_prefix = "/usr/local/postgres/bin" backup_options = concurrent_backup
51.
BaRMan導入方法 DB側はSRを許可する • postgresql.conf • pg_hba.conf •
リストア用にOS上でsshログインを許可 wal_level = ‘hot_standby’or ‘replica’ max_wal_senders = 1以上 max_replication_slots = 1以上 host replication barman 192.168.xx.xx/xx xxxx
52.
BaRMan導入方法 バックアップ取得、リストアは全てBaRMan 導入サーバから行う • Walストリーミング開始 • ベースバックアップ取得 barman
receive-wal --create-slot <サーバ名> barman cron barman check ←確認コマンド barman backup <サーバ名>
53.
BaRMan導入方法 • バックアップのカタログ機能で複数サー バの取得状況を確認 # barman
list-backup all ※一部省略 db003-5432 20171025...- Size: 1.1 GiB - WAL Size: 688.0 MiB db003-5432 20171018...- Size: 984.2 MiB - WAL Size: 1.7 GiB db004-5432 20171025...- Size: 98.2 MiB - WAL Size: 0 B db004-5432 20171018...- Size: 108.5 MiB - WAL Size: 48.0 MiB db005-5432 20171025...- Size: 339.3 MiB - WAL Size: 0 B ※再掲
54.
BaRMan導入方法 • ローカルリストア • リモートリストア barman
recover --target-time '2017-10-25 12:30:00+09:00' db001.slave-5432 20171025T010002 /var/pgsql/data-20171025 barman recover --remote-ssh-command 'ssh postgres@db001' -- target-time '2017-10-25 12:30:00+09:00' db001.slave-5432 20171025T010002 /var/pgsql/data-20171025 ※ローカルとリモートの違いは”—remote-ssh-command”の有無
55.
まとめ ばーまん→
56.
まとめ BaRManを導入するとこれが嬉しい • 複数のDBを一元的に管理できる • PostgreSQLのプロトコルでバックアップできる •
DB側はSRの設定をしておくだけ • PostgreSQL9.4以降ならレプリケーションスロッ トと組み合わせてwal管理からも解放される 以上、ご清聴ありがとうございました。 m( _ _ )m
Download now