1 / 17

Redundancy Control For PostgreSQL

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

melissa-becker
Download Presentation

Redundancy Control For PostgreSQL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Redundancy Control For PostgreSQL S-Queue-L Khurrum A Mujeeb, Adam Abu Hijleh, Adam Ali Stephen McDonald, Wisam Zaghal CISC 322 - 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 • LessonsLearned • Conclusion

  3. 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

  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

  5. Motivation: StakeholdersInterests

  6. 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

  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

  8. Selected Architecture for Redundancy Control

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

  10. Redundancy Control Subsystem 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

  12. 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

  13. 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

  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

  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

  16. 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

  17. 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

More Related