Confirm
358
edits
Changes
→The UserDB System
https://docs.services.mozilla.com/token/index.html
However, we intend for it to manage a relatively small number of clusters, which each have their own internal sharding or other scaling techniques, rather than managing a large number of service node shards. We're also going to simplify some of the secrets/signing management, and are not supporting trying to support multiple services from a single user account.
It also needs to be highly available for reads, since if UserDB read capability goes down, then we lose the ability for clients to access "log in" across all clusters.
To keep things simple and reliable and available, this will use a Multi-DC Replicated MySQL setup. It would be awesome if the write load is small enough to do '''synchronous''' replication here, using something like Galera cluster:
http://codership.com/content/using-galera-cluster
If not, then a standard master/slave setup should be OK. As long as we're careful about send no to give users to stale cluster assignments.
Example schema:
CREATE TABLE users
userid INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY
email VARCHAR(128) NOT NULLUNIQUE
clusterid INTEGER NOT NULL
previous_clusterid INTEGER
Each user is assigned to a particular cluster. We can also track the cluster they were previously assigned to, which might to help with managing migration of users between clusters.
CREATE TABLE clusters
assignment_weight INTEGER NOT NULL
Each cluster as a base_url and an assignment_weight. When a new user account gets created, we randomly assignment the assign them to a cluster with probability proportional to the assignment_weight. Set it to zero to stop sending new users to a particular cluster.
This service will need to have a user-facing API to support the login handshake dance, and some private management APIs for managing clusters, assignments, etc. Maybe even a nice friendly admin UI for the ops folks to use.
== A Massively-Sharded MySQL Cluster ==
