170 likes | 257 Views
Redundancy Control For PostgreSQL. S-Queue-L Khurrum A Mujeeb, Adam Abu Hijleh, Adam Ali Stephen McDonald, Wisam Zaghal. CISC 322 - Fall 2010. Overview. Motivation for Redundancy Control SAAM Analysis Stakeholders & Interests
E N D
Redundancy Control For PostgreSQL S-Queue-L Khurrum A Mujeeb, Adam Abu Hijleh, Adam Ali Stephen McDonald, Wisam Zaghal CISC 322 - Fall 2010
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 • LessonsLearned • Conclusion
WhatisRedundancy? Redundancy is having two or more independent components, be it processes or data, with the exact same purposeLets say we have an employee database which contains 2 rows of the following data EmpnumEmp Name Age 12345 John 25 12345 John 25
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
PotentialConceptual 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
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
ImpactedSubsystems - All subsystems affected, due to Redundancy Control acting as a “link” between the upper and lower layer
Redundancy Control Subsystem Legend Components External subsystems Depend on Depends on Subsystems
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
Client Library Interface Server 1 Server 2 Backend 1 Backend 2 Redundancy control 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 Executed Query Returned Legend: User Function Call Components Duration of running component Data Flow
Comparison of PotentialRisks & Limitations 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
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
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
LessonsLearned • 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
Conclusions • We have decided to implement Redundancy Control, utilizingthree machines; one for the client communication and redundancy control, and one of the twobackends • We are doingthisutilizing a layered architecture • The main goal of ourimplementationis to INCREASE reliability, with a smallreduction in performance, and an increasedfinancialcost