Change Details

Planned operations maintenance this week: # Replace `notify001`, which is scheduled for AWS downtime on September 20th. # T12932-related volume expansions: # Upgrade `dbak001` to 128GB (from 64GB). # Upgrade `dbak002` to 128GB (from 64GB). # Upgrade `ddata001` to 256GB (from 64GB). This will involve downtime for this shard. # Upgrade `ddata002` to 256GB (from 64GB). This will involve downtime for this shard. # (T12819) Rebuild all indexes on all active instances to populate Ferret engine data. Steps (1), (2A), and (2B) are not especially disruptive and can happen any time. Steps (2C) and (2D) are disruptive and I expect to complete them off-peak alongside deployment. Step (3) must happen after deployment. Also desirable is improving maintenance notifications so shards have a less disruptive experience ("Scheduled maintenance" instead of "oops, it's totally broken"). This isn't strictly necessary but will also make later work on shard compaction smoother.

Planned operations maintenance this week: # Replace `notify001`, which is scheduled for AWS downtime on September 20th. # T12932-related volume expansions: # Upgrade `dbak001` to 128GB (from 64GB). # Upgrade `dbak002` to 128GB (from 64GB). # Upgrade `ddata001` to 256GB (from 64GB). This will involve downtime for this shard. # Upgrade `ddata002` to 256GB (from 64GB). This will involve downtime for this shard. # (T12819) Rebuild all indexes on all active instances to populate Ferret engine data. Steps (1), (2A), and (2B) are not especially disruptive and can happen any time. Steps (2C) and (2D) are disruptive and I expect to complete them off-peak alongside deployment. Step (3) must happen after deployment. Also desirable is improving maintenance notifications so shards have a less disruptive experience ("Scheduled maintenance" instead of "oops, it's totally broken"). This isn't strictly necessary but will also make later work on shard compaction smoother. --- Also: - T12983, decommission `vault001`. - T12608, cycle the `master.key`.

Planned operations maintenance this week: # Replace `notify001`, which is scheduled for AWS downtime on September 20th. # T12932-related volume expansions: # Upgrade `dbak001` to 128GB (from 64GB). # Upgrade `dbak002` to 128GB (from 64GB). # Upgrade `ddata001` to 256GB (from 64GB). This will involve downtime for this shard. # Upgrade `ddata002` to 256GB (from 64GB). This will involve downtime for this shard. # (T12819) Rebuild all indexes on all active instances to populate Ferret engine data. Steps (1), (2A), and (2B) are not especially disruptive and can happen any time. Steps (2C) and (2D) are disruptive and I expect to complete them off-peak alongside deployment. Step (3) must happen after deployment. Also desirable is improving maintenance notifications so shards have a less disruptive experience ("Scheduled maintenance" instead of "oops, it's totally broken"). This isn't strictly necessary but will also make later work on shard compaction smoother. --- Also: - T12983, decommission `vault001`. - T12608, cycle the `master.key`.