Last modified: 2014-07-28 17:29:48 UTC
Doesn't have any private information since all renames are publicly logged. Wanted so I can add some basic monitoring of global renames.
That table is available (but empty atm).
Yes, it maintains status of CentralAuth renameuser jobs and if there are no jobs running (most of the time) the table is empty.
[23:21:20] <legoktm> Coren: MariaDB [centralauth_p]> select * from renameuser_status; [23:21:20] <legoktm> ERROR 1146 (42S02): Table 'centralauth_p.renameuser_status' doesn't exist [23:21:40] <Coren> o_O? [23:21:46] <Coren> Oh, the table exists not the view. [23:22:01] <Coren> That'll occur automagically next run of maintain-replicas, sometime tomorrow.
It's been 24+ hours and the table still isn't available...
..? MariaDB [centralauth_p]> select * from renameuser_status; Empty set (0.01 sec) Works for me! -- Marc
[10:25:46] <legoktm> Coren: MariaDB [centralauth_p]> select * from renameuser_status; [10:25:46] <legoktm> ERROR 1146 (42S02): Table 'centralauth_p.renameuser_status' doesn't exist [10:25:55] <legoktm> Coren: am I doing something wrong? >.> [10:26:07] <legoktm> Coren: this is using the "legobot" tool [10:26:21] <Coren> legoktm: I... wut? [10:26:28] <Coren> legoktm: I don't even. [10:26:39] Coren tries to figure out what goes. [10:27:24] <Coren> Oh! OH! Yeah, nothing you're doing wrong, just an odd side effect of the migration-in-progress. New changes to schemas, etc are applying only to the new combined instances! [10:28:04] <Coren> legoktm: Use the centralauth_p on c2.labsdb. The difference will be gone in a couple days when we migrated the rest of the databases. [10:28:38] <legoktm> sweet :D [10:28:39] <legoktm> works! tools.legobot@tools-login:~$ mysql -hc2.labsdb centralauth_p MariaDB [centralauth_p]> select * from renameuser_status; Empty set (0.01 sec)
