<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">- All -<div><br></div><div>After several meetings regarding realtime data and how it interacts with the database in the larger scope of the EHP web site, we have come to the following solution:</div><div><br></div><div>All realtime earthquake applications (RecentEQS, Shakmap, PAGER, DYFI, etc...) that uses a database shall run only on EHPMaster and EHPBackup; furthermore they will run independently between the two servers (no replication). They will all use a common, "realtime" MySQL database. On the primary server (currently EHPMaster), this database will be replicated out to the public web servers (EHP1-4).</div><div><br></div><div><i><b>Digression</b>: Similarly, <span class="Apple-style-span" style="text-decoration: underline;">f</span><span class="Apple-style-span" style="text-decoration: underline;">ile content</span> generated by realtime systems should also be generated exclusively on EHPMaster and EHPBackup and the current primary server should be configured to replicate file content to the public web servers.</i></div><div><br></div><div>Each of the public web servers will be allowed <b>read-only</b> access to their local (replicated) copy of the realtime data. A public web server is not allowed to write content back to the master database. There will be one common, shared user, "web", that will be used for all reads on any table in the realtime database.</div><div><br></div><div>Each realtime data provider (application) will additionally be given an unique application user account that is able to perform read/write queries. This account will only have access granted from localhost on each of the master servers (i.e. EHPMaster can perform writes to its local database, EHPBackup can perform writes to its local database). Additionally, each application-specific write user will only be granted privileges to write to tables in that application's namespace (see below).</div><div><br></div><div>In order to share a single database for all realtime products, each application should determine a prefix, "namespace" for its tables. Additionally, if an application is undergoing a major version revision, each version revision should be given its own namespace as well. (i.e. ExpoPAGER -> LossPager). All table names for a given application/version should be prefixed with the determined namespace identifier. This applies even to applications that use a single table. Following the namespace will be an underscore, "_", followed by the actual table name, for example: <font class="Apple-style-span" face="Courier" size="3"><span class="Apple-style-span" style="font-size: 12px;">pager_event, pager_version, pager_exposure</span></font> . Here, "pager" is the namespace and "event", "version", "exposure" are the table names (this is an example only and does not reference actual tables).</div><div><br></div><div>We recognize there are already several production-level realtime applications running on the public web servers that do not follow these rules. They can and will continue to run in their current state, however, as time permits for these applications to be updated and for any future application deployment, these new rules will be enforced.</div><div><br></div><div>If you have questions or concerns regarding these rules please let me know. If there is enough confusion/interest we can have a brief meeting to discuss these rules and their implications. These rules will require improved communication between application developers and server administrators and are meant to help us organize data, prevent confusion, and prevent broken applications similar to what occurred in the past few days following significant events.</div><div><br></div><div>Thanks,</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>~Eric.</div></body></html>