Top10 list planningpostgresdeployment.2014

The Top 10 List for Planning a Postgres Deployment
To listen to the recording of this presentation, please visit www.enterprisedb.com -
click on the Resources tab – and view the list of On-Demand Webcasts
© 2014 EDB All rights reserved. 1

Agenda
• EnterpriseDB Overview
• Preparation, Planning, and Postgres
• Top 10 Questions to Ask
• Ongoing Questions and Dealing with Change
• Summary and Resources
• Q&A
© 2014 EnterpriseDB Corporation. All rights reserved. 2

Brief EDB Overview

POSTGRES
innovation
Services
& training
ENTERPRISE
reliability
24/7
support
Enterprise-class
features & tools
Indemnification
Product
road-map
Control
Thousands
of developers
Fast
development
cycles
Low cost
No vendor
lock-in
Advanced
features
Enabling commercial
adoption of Postgres

Postgres Plus
Advanced Server Postgres Plus
Management Performance
Cloud Database
High Availability
REMOTE
DBA 24x7
SUPPORT
PROFESSIONAL
SERVICES
TRAINING
EDB Serves
All Your Postgres Needs
PostgreSQL
Security

EDB Customers
EDB currently has over 2,500 total customers including 50 of the Fortune
500 and 98 of the Forbes Global 2000

Gartner 2014 ODBMS Magic Quadrant
Gartner Comments:
• “EnterpriseDB is the primary
contributor to the PostgreSQL
Community”
• “EnterpriseDB’s Postgres Plus
Oracle compatibility is now more
than sufficient to run both
mission-critical and nonmission-critical
applications”
• “Infor, a major application
platform independent software
vendor, added EnterpriseDB as
a DBMS platform choice”
• “Reference customers continue
to identify the compatibility with
Oracle, the stability of the DBMS
and the product support as
strengths”

Preparation, Planning,
and Postgres

Deployment Planning ‘Timeline’
Hardware (Acquire and Configure)
Application (Usage Pattern, Response
Expectations)
Availability Requirements
Upgrades
Recovery (Objectives and Continuity)

Why? When?
• Why ask these questions?
− Keep everyone on the same page
− Not everyone knows what you know
− Your answers might mean something unforeseen by others
• When to ask these questions?
− Early
− Often
© 2011 EnterpriseDB . All rights reserved.

Quick Poll
Postgres Database Maturity Stage

Audience Quick Poll #1
• Question: What stage are you currently in with your
Postgres project?
• Answer choices:
a. Evaluation or Proof of Concept
b. Development – active development
c. Deployment – planning for production or recently launched
d. Maintenance

The Top 10 List

10 Questions to Ask Yourself and Others
1. Where should I focus my money?
2. How should I partition the I/O?
3. What does my app want?
4. Can my app handle what the DB offers?
5. Highly available or highly recoverable?
6. Is ASYNC enough or do I need SYNC?
7. Cascaded replication or fanned?
8. How do I upgrade?
9. Why upgrade?
10. How much data can I afford to lose?

Hardware

1. Acquiring Hardware – Where should I
focus my money?
• Where should I focus my money?
− RAM
− Max it out
− ECC
− I/O
− Low latency
− Battery backed
− Local, not network
− CPU
− More cache == more better
− Less CPUs, more cores
− One 12-core CPU > Two 6-core CPU

2. How Should I Partition the I/O ?
http://www.enterprisedb.com/ahc
• $PGDATA/pg_xlog
− SSDs
− ext2
• $PGDATA/pg_log
− syslog
• $PGDATA/pg_stat_tmp
− tmpfs
• $PGDATA/base
− zfs, ext4, xfs - YES
− btrfs - not yet
− ext3 - NO

I/O Partitioning (cont.)
• Tablespaces (you should be using them)
− Group like objects into a tablespace of their own
− Indexes
− Reporting/historical tables
− zfs, ext4, xfs
− Indexes on SSD
• Things to avoid
− Hardware deduplication (just don't)
− Hybrid SSD/HDD (use tablespaces instead)
− NFS, GlusterFS, FUSE, remote* storage

File System and Storage Subsystem
• Types of Storage Systems
− Direct Attached Storage (DAS)
− Storage Area Network (SAN) w. Fiber Channel
− Storage Area Network (SAN) w. iSCSI
− Network File System (NFS)
• DAS: Fast and low latency
• SAN: Fast, expensive (w. Fiber Channel), scalable, can
include redundancy and smart file system operations
• NFS: Not an optimal solution for Postgres

Your Application

3. What Does My App Want?
• A few long-running connections crunching lots of data?
− large work_mem
− Emphasize effective_cache over shared_buffers
• Lots of 'quick hit' connections?
− connection pooling
− larger shared_buffers
• More read? Or more write?
− autovacuum aggressiveness
− Checkpoint spreading

4. Can My App Handle what the DB Offers?
• Can the app recover from a failed
transaction?
− During failover, for example
• Can the app re-request if the answer
isn't up-to-date?
− Read-only slave, slightly behind the
master
• Can the app handle 'eventual
consistency'?
− Multi-master replication

Availability

5. High Availability or High Recoverability?
• Highly available
− Enterprise Failover Manager (EFM)
− xDB
• Highly recoverable
− Warm standby
− WAL archiving
− PITR
• Geographically durable
− xDB
− Cascaded Replication

6. Is ASYNC Enough or Do I Need SYNC?
• ASYNC Replication
− Default
− Eventually consistent
− May be 1+ transactions behind
− Unlimited* number of ASYNC slaves
• SYNC Replication
− Atypical
− Immediately consistent
− Performance implications on the master
− Only ever one SYNC slave

7. Cascaded or Fanned Replication?
• Cascaded
− Can survive death of the master
− May introduce replication lag
• Fanned
− Does not survive death of the master
− No additional replication lag
• Both
− No reason you can't mix-n-match
OR

Upgrades

Quick Poll
Upgrade Policies

Audience Quick Poll #2
• Question: What is your current upgrade policy?
• Answer choices:
a. Fully defined patch mgmt. policy w/ standing maintenance
windows
b. We apply security fixes only as needed
c. We apply patches/upgrades whenever the mood strikes us
d. We apply patches/upgrades when the vendor forces it
e. Upgrades?

8. How Do I Upgrade?
• Postgres version number: xx.yy.zz
− xx.yy = major version (8.4, 9.2, 9.3)
− zz = minor version (9.1.14, 9.3.5)
• Current version:
− 9.3.x → 9.3.5
− 9.2.x → 9.2.9
• Major version changes
− Not backwards compatible for stored data
− Dump/load
− pg_upgrade
• Minor version changes
− Replace the binaries, restart

How Do I Upgrade (cont.)?
• Use replication !
• Upgrade the slave first
− If a minor release upgrade, streaming replication
− If a major release upgrade, logical replication
• Failover to the upgraded slave
• Upgrade the old master
• Slave the old master to the new master
• Fail back (optional)

9. Why Upgrade?
• Postgres minor releases fix only:
− Frequently-encountered bugs
− Security bugs
− Data corruption bugs
• As such, you are more at risk by not upgrading
• Major versions are supported for 5 years which lessens
the upgrade burden significantly

Recovery

10. How Much Data Can I Afford to Lose?
• What’s the loss to the business per minute of the app
being down?
− High cost == design for high availability
− Think multi-master replication
− Think offsite replication
− Think automatic failover
• What’s the loss to the business for every transaction
you can’t recover?
− High cost == design for high recoverability
− Think SYNC replication
− Think continuous WAL archiving
− Think outside the db (zfs snapshots, RHCS, Veritas clustering)

Why Do I Need Backup and Recovery?
• Backup and Recovery Strategies protect you in case of:
− Catastrophic device failure
− Site failure
− Maintenance
− Operator error
− Compliance
− Data corruption
• Consider
− Allowable PITR timeframe
− Data retention policy
− Test, test, test
− Periodic backup validation

What Are My Recovery Options?
• Various recovery options are available:
− PITR
− BART / Barman
− pg_basebackup
− pg_dump
• How long does restoration take?
• Do I know how to restore using my chosen method?

Dealing with Change –
Ongoing Questions

Moving Forward
• When things change
− Database load
− Hardware
− Software versions
− Business needs
− User base grows
And
• At minimum, annually
=> Reconsider all questions

Summary and Useful Resources

Summary
• Preparation, Planning, and Postgres
− Most problems occur after moving to production
− Many times these problems were foreshadowed
− Try to think of “what's next” as much as “what's now”
• Communicate
− Nothing exists in a vacuum
− Seek input from other teams
− Proactively “push” info to others
• Evaluate, Adjust, and Repeat
− Monitor all the things
− Define your 'line in the sand'

What You Can Do
• Get the team ready for Postgres - Developer, DBA, Infrastructure
• EDB Knowledge Base
• Get Certified - http://www.enterprisedb.com/training
• Follow the conversation:
− #postgres on Twitter
− Planet PostgreSQL, @planetpostgres , http://planet.postgresql.org
• User groups and Meetups – almost all major cities
− http://www.postgresql.org/community/user-groups/
− http://postgresql.meetup.com/

Architectural
Health Check
• Review of
database,
OS, env.
settings
• Guidance on
tuning,
backup, high
availability
strategies
Kick Start
• Training
• Flex
consulting
• Developer
subscription
Training and
Certification
• Flexible
formats:
on-demand,
live virtual,
on-site
• Continuing
education
and Postgres
certification
Remote DBA
Services
• 24 x 7
monitoring
• Supplemental
staff
• Architectural
health check
• Access to
Postgres
expertise
How We Can Help
Whitepapers and Recorded Webinars
http://www.enterprisedb.com/resources-community

To listen to the recording of this presentation, visit www.enterprisedb.com - click on
the Resources tab – and view the list of On-Demand Webcasts.
To learn more about EDB’s Subscription Options, please contact
sales@enterprisedb.com

Top10 list planningpostgresdeployment.2014

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Top10 list planningpostgresdeployment.2014

Semelhante a Top10 list planningpostgresdeployment.2014 (20)

Mais de EDB

Mais de EDB (20)

Último

Último (20)

Top10 list planningpostgresdeployment.2014