Very alpha draft; document may contain design philosophy and pointless asides as well as practical, useful information.

Architecture

Each store has its own IS4C server. This server is responsible for managing that store's lanes. One server may be denoted the Master server. Functionally, all servers have the same software. The Master server just gets to wear a special hat.

The advantages of having what's basically a two tier system despite three obvious tiers (lane, store server, master organization-wide server) are flexibility in provisioning and robustness in the event of failure.

A two store operation could purchase two store servers, one for each store, and simply denote on of them master. Alternatively, they could purchase three store servers, one for each store and a third with no actual lanes of its own to act as master. In the two store, three server set up, the organization can temporarily cope with any single hardware failure with simple configuration changes; there's no additional software to install.

Configuration

There's a Stores link at the top of Fannie's configuration. Each store server has its own copy of Fannie and own unique configuration file. Configuration for each server is as follows:
  1. Enter the number of other stores and re-run to expose additional fields. Remember, a dedicated master server counts as a store, too.
  2. Enter databse connection information for the other stores. Technically, only the master store needs to know about all stores; the other stores just need to know how to reach the master.
  3. Mark which store server is the Master.
  4. Enter the name of the archive database for the Master server.
  5. Hit re-run again to save additional configuration.

Store => Master Transaction Info

Since the Master Store is functionally identical to other stores, transaction data is archived in the same way. Snapshot tables exist for each month and the transarchive table holds the previous 90 days. If the master server is a dedicated machine with no lanes, dtransactions will simply be empty. See DBA docs for more info on transaction archive structure.

The provided cron script nightly.hq.dtrans.php will transfer transaction data from a store to the master database. First it creates a temporary table on the master server. This table is named based on the store's IP. If multiple stores are sending data to master simultaneously and different store servers have the same IP, this could go haywire. Give your store servers different IPs. The store then copies its dtransactions to the temporary table on master.

Next the script copies data from the temporary table into transarchive and the appropriate monthly snapshot. Finally it drops the temporary table. Overall, using a temporary table should be slightly faster since data only goes over the network once. The extra, unique table also simplifies concurrency issues if multiple stores are submitting transaction data to master simultaneously.

Misc: this job should happen before the store's local transaction archiving, or dtransactions will be empty. This also copies data one record at a time to accomodate WFC's mess of a store server on SQL Server + Windows and a master server on MySQL + OS X (and the Apache side of Fannie on CentOS for maximum platform inconsistency... er platform independence...). Piping mysqldump would probably be faster if all machines are MySQL, but current performance is still only 30-40 seconds, tops.

Syncing Operational Data

Manual syncing is accessible from Fannie. Click Synchronize, then Synch Stores. Options depend on whether you're at the master store. You can send a table: This tool replaces data at the destination store(s) rather than adds to it.