[10:34:58] so cloning stuff on es: the plan is to clone each server once [10:35:52] That way, we minimize potential physical corruption because of disk, filesystem, rows missing because of maintenance etc. [10:36:54] once we have migrated to the new servers, I will perform a last checksum to verify there is also no problems in cloning [12:00:46] Hey jynus. Do you know why MediaWiki db schema avoids REFERENCES? [12:15:08] I do not know why, but I can guess [12:15:42] please note that I am not the "owner" I only cry aloud when something is too wrong [12:15:50] (of the schema) [12:16:02] that's fine :) [12:17:07] probably the main reason is history, probably MyISAM was the default engine in 2000 [12:18:05] that is the same reason why we store timestamps in binary fields and our default charset is binary [12:19:10] it is not that those things cannot be fixed now, but it will take away a lot of resources [12:19:54] ok, thanks [12:20:00] more recently, sqlite support ,than in recent versions [12:20:15] asked because of the comment at https://www.mediawiki.org/wiki/User:Bawolff/review/Newsletter#SQL [12:20:15] already has FK support, but [12:20:54] there is also some small potential performance that could be lost do the extra locking [12:21:11] that may need debugging, and again, resources that we may not have [12:22:24] I see some worse lies there [12:23:21] "VARCHAR (256) is a bit odd. 255 is the max varchar size where the overhead is only 1 byte." [12:24:45] I wrote about that on: http://dba.stackexchange.com/questions/76469/mysql-varchar-length-and-performance/76470#76470 [12:25:08] although we use the binary collation, to be fair [12:25:17] *binary charset [12:27:51] I would like some of those legacy options fixed, specially if they create issues: https://phabricator.wikimedia.org/T108255