Legend

candlewhynotData Management

Jan 31, 2013 (4 years and 4 months ago)

199 views

Redundancy

Control For
PostgreSQL


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



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

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

Motivation:
Stakeholders

Interests

Stakeholder

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

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

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



Selected

Architecture for
Redundancy Control

Impacted

Subsystems

-

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



Redundancy Control
Subsystem

Legend







Components

Depends on

External subsystems

Depend 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

Request to

Log in

Request to

Log in

Server and communi
-

cation channel created

Logged

in

Redundancy
control

Backend 2

Server

Requested

Server

Requested

Server 2

Backend 1

Query Sent

Query Sent

Executed Query

Returned

Executed Query


Returned

Server 1 Not

Responding

Executed

Query

Returned

Executed

Query

Returned

Executed

Query

Returned

Executed

Query

Returned

Query

Sent

Query

Sent

Query

Sent



Legend:

Components

Data Flow

Function Call

Duration of

running

component

User

Server spawned

Use Case:


Server 1 Fails

Comparison

of
Potential

Risks

&
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


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


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