1. Redundancy Control For PostgreSQL
everyone
S-Queue-L
Khurrum A Mujeeb, Adam Abu Hijleh, Adam Ali
Stephen McDonald, Wisam Zaghal
CISC Fall 2010

2. Overview Motivation for Redundancy Control SAAM Analysis
Stakeholders & Interests
Possible Implementations of Redundancy based on architecture design
Comparison of designs
Our chosen architecture
Redundancy Subsystem
Use Case
Risks and limitations of Redundancy Implementation
Effects on Concurrency and Team Issues
Limitations
Lessons Learned
Conclusion
adam

3. What is Redundancy?
Redundancy is having two or more independent components, be it processes or data, with the exact same purpose Lets say we have an employee database which contains 2 rows of the following data Emp num Emp Name Age John John 25
adam

4. Motivation for Redundancy Control
Increase server reliability & availability by decreasing the chances of a complete server failure
If one server crashes queries still get processed as if there was no crash
Current implementation uses a “hot standby” server in case of failover
Asynchronous – Secondary server data is not sync’d in real time, but is updated when needed or at regular intervals
Read only queries
New Implementation increases reliability and availability while sacrificing performance and increased cost
Synchronous – Secondary server must be updated concurrently
Read/Write queries allowed on both servers
adam

5. Motivation: Stakeholders Interests
Non-Functional Requirements
PostgreSQL Developers
Maintainability
End Users of PostgreSQL
Reliability, Availibility, Performance, Usability, Security
CommitFest Reviewers
Testability
Network Administrators of Backend Server
Reliability, Security, Scalability
adam
Stakeholder
Non-Functional Requirement
PostgreSQL Developers
Maintainability
End Users
Reliability, Performance, Availability,
Usability,
Security
CommitFest
Reviewers
Testability,
Performance, Reliability,
Portability
Network Administrator of Backend Server
Reliability,
Security,
Scalability

6. Potential Conceptual Architecture for Redundancy Control
Layered Architecture
Client communicates with the redundancy control layer which in turn communicates with Postgres
Object Oriented Architecture
All subsystems communicate directly with each other
stephen

7. Comparative Advantages
Layered Approach Advantages:
Greater security and testability, and, in the event of the redundancy subsystem crashing, maintains data integrity
Object-Oriented Approach Advantages:
Better performance and availability
khurrum

8. Selected Architecture for Redundancy Control
stephen

9. Impacted Subsystems
- All subsystems affected, due to Redundancy Control acting as a “link” between the upper and lower layer
stephen

10. Redundancy Control Subsystem
stephen
Legend
Components
External subsystems
Depend on
Depends on
Subsystems

11. Testing Impact of Enhancement
Regression Testing
make sure software does not become less effective that in the past
Functionality tests
- black box testing
- test every time a feature is added, changed or extended
Failure tests
- examples that have caused failures in the past
- before correcting failure, find out what caused it and save it
- re run on all future versions
Operational Tests
- ensure existing/intended functionality/behavior not lost
- catches accidental or unintentional changes
stephen

12. Use Case: Server 1 Fails Legend: Baby Adam Function Call User
Client
Library Interface
Redundancy control
Server 1
Server 2
Backend 1
Backend 2
Request to
Log in
Request to
Log in
Logged in
Server
Requested
Server
Requested
Server spawned
Use Case:
Server 1 Fails
Server and communi-
cation channel created
Query
Sent
Query
Sent
Query
Sent
Query Sent
Query Sent
Server 1 Not
Responding
Executed
Query
Returned
Executed
Query
Returned
Executed
Query
Returned
Executed Query
Returned
Executed Query
Returned
Baby Adam
Executed
Query
Returned
Legend:
Function Call
User
Components
Duration of
running
component
Data Flow

13. Comparison of Potential Risks & Limitations
Further expenses are required to introduce an additional servers
Backend Servers must be Identical
Risks:
Entire system is reliant upon the Redundancy Control subsystem
No failover in the case when both servers are down
khurrum

14. Concurrency & Team Issues
Submissions of new enhancements have to added to next CommitFest
New team to manage redundancy control, test the code frequently and make sure there are no bugs
Further personnel
Concurrency controls remain the same as currently implemented
khurrum

15. Limitations
Due to the lack of knowledge about SQL Database Management Systems within the group, coming up with an enhancement was very challenging
Determining what Postgres has implemented with regards to data backup systems
We had to assume that our new implementation could be easily integrated in a layered architecture
Baby adam

16. Lessons Learned
Currently, the majority of SQL Database Systems have an asynchronous redundancy feature available, as synchronous is very expensive to maintain and set-up
Understanding the difference between synchronous and asynchronous was crucial before suggesting alternatives
Baby adam

17. Conclusions
We have decided to implement Redundancy Control, utilizing three machines; one for the client communication and redundancy control, and one of the two backends
We are doing this utilizing a layered architecture
The main goal of our implementation is to INCREASE reliability, with a small reduction in performance, and an increased financial cost
khurrum