Building a High-Availability PostgreSQL Cluster at ARIN

1,651 views
1,439 views

Published on

Through a long and intense period of research, implementation, and testing, ARIN completed the migration from Oracle to PostgreSQL late last year. Learn more at: http://teamarin.net/2014/04/01/building-high-availability-postgresql-cluster-arin/

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,651
On SlideShare
0
From Embeds
0
Number of Embeds
24
Actions
Shares
0
Downloads
22
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Building a High-Availability PostgreSQL Cluster at ARIN

  1. 1. Building a High-Availability PostgreSQL Cluster Presenter: Devon Mizelle System Administrator Co-Author: Steven Bambling System Administrator
  2. 2. What is ARIN? •Regional Internet registry for Canada, US, and parts of the Caribbean •Distributes IPv4 & IPv6 addresses and Autonomous System Numbers (Internet number resources) in the region •Provides authoritative WHOIS services for number resources in the region 2
  3. 3. ARIN’s Internal Data 3
  4. 4. Requirements 4
  5. 5. Why Not Slony or pgpool-II? • Slony replaces pgSQL‟s replication – Why do this? – Why not let pgSQL handle it? • Pgpool is not ACID-Compliant – Doesn‟t confirm writes to multiple nodes 5
  6. 6. Our solution • CMAN / Corosync – Red Hat + Open-source solution for cross- node communication • Pacemaker – Red Hat and Novell‟s solution for service management and fencing • Both under active development by Clusterlabs 6
  7. 7. CMAN/ Corosync • Provides a messaging framework between nodes • Handles a heartbeat between nodes – “Are you up and available?” – Does not provide „status‟ of service, Pacemaker does • Pacemaker uses Corosync to send messages between nodes 7
  8. 8. CMAN / Corosync 8
  9. 9. About Pacemaker • Developed / maintained by Red Hat and Novell • Scalable – Anywhere from a two-node to a 16- node setup • Scriptable – Resource scripts can be written in any language – Monitoring – Watches out for service state changes – Fencing – Disables a box and switches roles when failures occur • Shareable database between nodes about status of services / nodes 9
  10. 10. Pacemaker 10 Master AsyncSync
  11. 11. Other Pacemaker Resources 11 Fencing IP Addresses
  12. 12. How does it all tie together? From the bottom up…
  13. 13. Pacemaker 13 Client “vip”Replication “vip” Master Sync Async App
  14. 14. Event Scenario 14 Master Sync AsyncMaster SyncAsync
  15. 15. PostgreSQL • Still in charge of replicating data • The state of the service and how it starts is controlled by Pacemaker 15
  16. 16. Layout 16 💙 💙 MasterSlave Slave cman cman cman Client
  17. 17. Using Tools to Look Deeper Introspection…
  18. 18. # crm_mon -i 1 -Arf
  19. 19. # crm_mon –i 1 -Arf (cont)
  20. 20. Questions? Devon Mizelle

×