Hi, Otto, On Aug 16, Otto Kekäläinen wrote: > Hello Sergei and Yuchen! > > I was looking at the code Yuchen wrote this week [1]. Thinking back > about practical scenarios on how the redirect would be used to > gracefully decommission server A and have all existing and new > connections user server B instead (as laid out in this thread at end > of July [2]) I fail to see how it would work.
<...cut...> > I find it a bit concerning that in this model old clients, instead of > getting an error with a human readable explanation of what happened, > continue to read stale data. And only way to prevent that is to shut > down server A quickly, whereafter the old clients only get an error > about server not being reachable and nothing about the old client not > supporting redirects. Yes, if the client doesn't support redirects, it'll work as before - that is, the client will be kicked out when the server is shut down and then the client will connect to a new server because, of course, if there's failover, there must be some way of telling clients what server to connect to. The error will be ER_SERVER_SHUTDOWN which is what old clients were always getting in this case. So, basically, for old clients there will be no changes whatsoever. > Hence, I still feel that Daniel's submission [3,4] would be a better > design, being more robust and safer. An error+redirect is easier to > reason about regarding integrity of data and error modes than the > voluntary maybe-redirect that is now in the works by Yuchen. Hm. Technically, the server can check whether redirect_url is set, and send ER_SERVER_REDIRECT instead of ER_SERVER_SHUTDOWN. I'm not sure it'll be much of an improvement, but it's doable. But even in this case, the error message will only inform the user, the actual machine-readable actionable url will be in the session tracking data. Forcing the client to parse and extract actionable data from the error message that is designed to be user readable, this looks like a rather unsightly hack to me. > [1] https://github.com/MariaDB/server/commit/04b99a30a3f.patch). > [2] > https://lists.mariadb.org/hyperkitty/list/developers@lists.mariadb.org/thread/7UGBTX2B2KPH7UAXCCWFMUNIRQEA3WLS/#RIH7YJZIXP72L4DDFLFY37HJS2BJTZTM > [3] https://github.com/MariaDB/server/pull/2681 > [4] https://github.com/mariadb-corporation/mariadb-connector-c/pull/22 Regards, Sergei VP of MariaDB Server Engineering and secur...@mariadb.org _______________________________________________ developers mailing list -- developers@lists.mariadb.org To unsubscribe send an email to developers-le...@lists.mariadb.org
