While ORES in eqiad would not be receiving end-user traffic having oresrdb1001 down would lead to some alerts as precaching from changeprop would still take place. While not strictly necessary (we would have no problems), switching over to the slave and documenting the process would be beneficial, so let's do it.
Description
Details
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | faidon | T149226 cr1-eqiad:ae4 is disabled due to VRRP issue | |||
| Resolved | • Cmjohnson | T148506 Rack and setup new eqiad row D switch stack (EX4300/QFX5100) | |||
| Resolved | akosiaris | T163326 switchover oresrdb.svc.eqiad.wmnet from oresrdb1001 to oresrdb1002 and back (after T148506) |
Event Timeline
Change 349434 had a related patch set uploaded (by Alexandros Kosiaris):
[operations/dns@master] Switch oresrdb.svc.eqiad.wmnet to oresrdb1002
Change 349434 merged by Alexandros Kosiaris:
[operations/dns@master] Switch oresrdb.svc.eqiad.wmnet to oresrdb1002
This was done as well. There is an action item discovered during this which would be to automate this more using confd as is done for the jobqueue redis databases but it is not tied to this task.
Resolving
Change 350807 had a related patch set uploaded (by Alexandros Kosiaris; owner: Alexandros Kosiaris):
[operations/dns@master] Revert "Switch oresrdb.svc.eqiad.wmnet to oresrdb1002"
Change 350807 merged by Alexandros Kosiaris:
[operations/dns@master] Revert "Switch oresrdb.svc.eqiad.wmnet to oresrdb1002"