1 / 13

Schema Replication

Schema Replication. Schema Replication. Schema replication to use Bully algorithm Why? On create, must ensure unique table names across all schemas Need a recognised way of maintaining a master schema Can afford the time to validate each new entry in schema

fadhila
Download Presentation

Schema Replication

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. Schema Replication EDG WP3 Meeting 14/01/04 – 16/01/04 ptaylor@uk.ibm.com

  2. Schema Replication • Schema replication to use Bully algorithm • Why? • On create, must ensure unique table names across all schemas • Need a recognised way of maintaining a master schema • Can afford the time to validate each new entry in schema • Due to low frequency of updates on Schema tables • One Master schema per VO • Bully algorithm votes on master schema, if none exists • Master propagates ‘authorised’ updates to remaining schemas • Queries aimed at ‘local’ schemas • Queries handled locally, if possible, to reduce response time • Write-thru caching to reduce write times when update authorised EDG WP3 Meeting 14/01/04 – 16/01/04 ptaylor@uk.ibm.com

  3. local update update update read update authorisation replication XML message to propagate update ‘Do update’ update request Schema Update and Replication * Lowest id == highest priority Master – id 42 Slave – id 101 Schema Servlet Schema Servlet DB DB EDG WP3 Meeting 14/01/04 – 16/01/04 ptaylor@uk.ibm.com

  4. 1. Update 3. Master dies 2. Update auth. request Q (101) 6. Read P (42) Schema Servlet Schema Servlet DB DB 9. Update 7. Update 9. Update 5. Q is new Master 5. Q is new Master 8. Do update 8. Do update R (2001) S (2525) Schema Servlet Schema Servlet DB DB Bully Algorithm Animated • Event = No Master Response 4. No h-p processes. Assume Master role M M *h-p == higher-priority process EDG WP3 Meeting 14/01/04 – 16/01/04 ptaylor@uk.ibm.com

  5. Q (101) P (42) Schema Servlet Schema Servlet DB DB 2. Election request 5. P is new Master 3. No response (l-p) 2. Election request 2. Election request 5. P is new Master 5. P is new Master 3. No response (l-p) 3. No response (l-p) R (2001) S (2525) Schema Servlet Schema Servlet DB DB Bully Algorithm Animated • Event = Restart 1. Restart 4. No h-p. Assume Master role M M *l-p == lower-priority process EDG WP3 Meeting 14/01/04 – 16/01/04 ptaylor@uk.ibm.com

  6. 8. Election request Q (101) P (42) Schema Servlet Schema Servlet 15. Update DB DB 13. Read 14. Update authorised 11. Q is new Master 11. Q is new Master 5. ‘live’ response 2. Update auth. request 17. Do update 4. Election request h-p 12. Update auth. request R (2001) S (2525) Schema Servlet Schema Servlet 1. Update DB DB 18. Update 16. Update Bully Algorithm Animated • Event = Election Request Received 7. Take over election role 10. No other h-p process Assume Master role M M 9. No response (dead) 3. No response (dead) 6. h-p process exists. Suspend election and wait for new Master notification EDG WP3 Meeting 14/01/04 – 16/01/04 ptaylor@uk.ibm.com

  7. Bully Algorithm (Event = No Master Response) Process P attempts to do an update to the schema DB and notices that the Master is no longer responding to requests, so P initiates an election... (Event = Election Request Received) When a process receives an election message from a lower-priority process... • The receiver sends an 'ok' message back to the l-p process, indicating that it is alive and will take over the election process. • The receiver holds an election, unless it is already holding one. • Eventually all processes give up except one, the one with the highest-priority. • The new Master announces its victory by sending all other processes a message telling them that it is the new Master. • P sends an election message to all higher priority processes. • If no one responds, then P wins the election and becomes the new Master. • If one of the high-priority processes responds, then that h-p process takes over the election and P is done. (Event = Restart) If a process P that was previously down comes back up... • P holds an election. If P happens to be the highest-priority, then P wins the election and takes over the coordinator's job. EDG WP3 Meeting 14/01/04 – 16/01/04 ptaylor@uk.ibm.com

  8. Affected Classes • SchemaServlet* • Changes to doGet() and add Bully algorithm logic on createTable and synchronisation between schemas • SchemaReplicaCreator+ • Extract schema table data to replicate, based on certain rules • SchemaReplicaEncoder+ • Translate replication data to XML ready to post • SchemaReplicaSender+ • Send HTTP-post XML replication message to remote schemas • SchemaReplicaReceiver+ • Receive HTTP-post XML message of replication data • SchemaReplicaStorer+ • Decode XML data to internal structure to record replication data via RDBMS *Changes to existing class +Add new class EDG WP3 Meeting 14/01/04 – 16/01/04 ptaylor@uk.ibm.com

  9. Proposed Code Changes • SchemaServlet • In SchemaServlet() constructor • Initialise schemaElectionId, masterSchemaLocation, isMasterSchema, electionInProgress • Each time servlet starts… • Call electMasterSchema() to force an election • Call SynchroniseSchemaDB() • If isMasterSchema is false, then contact Master and synchronise DB state. • If isMasterSchema is true, then contact all Slaves and merge DB state. • This could be tricky! • What to do with inconsistencies? Vote on latest entry to win? Don’t delete if unsure • In doGet() • Add masterNotification(location) • Receives location of who is the new master and record this • Add electionRequest() • Respond to a lower-priority process and take over election process • In createTable(…) • If isMasterSchema is true, then attempt table create • May fail on duplicate table – handle error gracefully • Read current schema list and apply update to each one • Authorisation given if isMasterSchema is true • Else isMasterSchema is false, so get permission for table create • If remote Master is ‘dead’ force an election to get a new master appointed EDG WP3 Meeting 14/01/04 – 16/01/04 ptaylor@uk.ibm.com

  10. Proposed Code Changes • SchemaServlet • electSchemaMaster() • Initiate an election process • electionInProgress = true • Build a list of known higher-priority schemas • Each schema keeps full list of know schemas • Build ‘live’ list and record each entry’s priority id • A schema’s (unique and consistent) priority can be derived from the hashcode of its location string • Poll each h-p process for an ‘alive’ response • No response means that this process is the highest priority process • This process is now the master (masterSchemaLocation = this.schemaLocation) • Synchronise state with all other known schemas • Tell all the other processes the location of the new master • A response means that another process has a higher priority • electionInProgress = false (another h-p process initiates an election) • Eventually the h-p process will assume the role of Master EDG WP3 Meeting 14/01/04 – 16/01/04 ptaylor@uk.ibm.com

  11. Some Food for thought • Propagation of table updates • Need to ensure that all updates are carried out, even for postponed updates for schemas that are down when the ‘Do update’ message was sent. (See next bullet point). • Consistent state on start/restart • If a schema starts/restarts, then it must synchronise its internal state with that of the other schemas • Same consistency rule applies for potential Master, as well as Slaves. • If Master, then contact all Slaves and synchronise with them • Voting scheme required in case of inconsistency between slave’s state • If Slave, then contact Master and synchronise with it • Only then can the restarted schema be ‘alive and ready’ • Security • Validation of registries and schemas during replication • Do we know and/or trust who we’re sending to? • Adding a new registry or schema to the VO • Is this new registry or schema known and/or trusted? EDG WP3 Meeting 14/01/04 – 16/01/04 ptaylor@uk.ibm.com

  12. To do list • Sort out registry replication first! • Decide on which version to use • Replicate only new/changed data • Replicate all data regardless • Decide on which checksum mechanism to use • Check-in draft new schema replication classes • Change schema replication classes in-line with recent changes to registry replication classes and schema table changes • Integrate draft Java bully-algorithm logic into SchemaServlet code • Plug remaining gaps in bully logic for schema table updates • And propagating those updates (even if schema misses an update) • Generic table readers for registry and schema to build replication data • Security considerations on adding new registrys/schemas • Testing, testing, testing • Can make use of existing Junit unit tests for building registry replication messages, as a basis for testing schema replication class methods • Need new system testing for different Schema (Master/slave) replication model EDG WP3 Meeting 14/01/04 – 16/01/04 ptaylor@uk.ibm.com

  13. The End EDG WP3 Meeting 14/01/04 – 16/01/04 ptaylor@uk.ibm.com

More Related