Hi Vlad On 02/04/2011, at 7:05 AM, Vladislav Vaintroub wrote:
In current (5.2-main and 5.3-main MSI-based) setup, user can specify the datadirectory, port and root password, when database is created. Config file is tiny and typically has only datadir and port here and in no way "optimized". Windows packages are relocatable, hence I do not need either basedir nor language. Except missing sizes parameters, there is a difference to default MySQL installation in that sql_mode is not set (default in MySQL installations is strict) and storage engine is not set (default in MySQL installations is innodb). For me, it sounds like we could make many users happy, if we had a pre-selected "Quick configuration" checkbox (nothing wizard-driven), that would
-set sql_mode to strict -set default storage engine to innodb - give 12.5% or so of RAM to Innodb buffer pool (clearly not suitable for dedicated machines, but dedicated installs will need tweaking parameters anyway) . 12.5%RAM is something I borrowed from the ConfigWizard's default - set innodb log file size to a reasonable value, because changing this parameter afterwards is cumbersome.
Ideally there would be an integer input field with "how much memory (in MB) do you want to dedicate to this MariaDB instance" with 12.5%RAM being default.
My initial thought when the whole discussion about improved templates has started started was to reuse the "one true template" for windows. But now I'm not really sure, anything I have seen so far would not run on Windows when used as-is, and (for my own taste) overspecified, often repeating defaults. I personally would prefer a minimal OS-agnostic template, but I think way forward is to go on and roll out my own solution for those 4 extra parameters.
somewhere along there we can resolve that separately. Since Windows is not a *nix, all the paths are different. All other platforms are *nix based. Right?
*nix is not *nix, its standards can't agree with each other. MySQL packaging legacy adds yet another dimension to it. RPM package layout is different from DEB package layout and different from tar.gz. On Solaris, packages are getting installed into /opt , on OSX and after "make install" to /usr/local/mysql. And so on. The hardcoded paths will still be issue there.
So I think we agree that fixing up the build-time defaults would work best then, since that that point we know what we're building for, right? The problem with changing compiled-in defaults is that if an existing installation relies on a certain old incorrect setting, it'll break on upgrade. Since people tend to not simply replace running configs with example configs in a production system, having changes in a (sample/ default) config file is sufficiently safe. So, what do we do? Regards, Arjen. -- Arjen Lentz, Exec.Director @ Open Query (http://openquery.com) Remote expertise & maintenance for MySQL/MariaDB server environments. Follow us at http://openquery.com/blog/ & http://twitter.com/openquery