maria-discuss team mailing list archive

["Jakob Lorberblatt" <jakob@xxxxxxxxxxxxxxxxxxxxxxx>]

In regards to the concept of broken config's being required for existing
installs, the simplest 'solution' would be a migration 'dump' of values
set in comparison to a list of the defaults inbound, then subtract the
existing values in the configuration file. This has worked for me and is
hinged only on having access to the database itself (while still running,
prior to upgrade) which presumably someone upgrading the software should
have. I understand this requires a separate utility that does not exist in
the source tree as it stands, in addition it needs to be adjusted for
compatibility with the various platforms, so more than a suggestion it
might not really be.
   On the topic of defaults, in production I have never been able to use
defaults as is,  possibly overkill for many but my experience is that
read_random_buffer_size should be set to something like 256M before it
stops improving performance noticeably for primarily MYISAM usage. My
point being that differing environments make many defaults seem
questionable.
   The old sample configs have to go though, for sure, a simple defaults
file, or a little fine tuning to the 'wizard' style interface used on
windows may be better for many newer or less experienced users.

Jakob Lorberblatt

> 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
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~maria-discuss
> Post to     : maria-discuss@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maria-discuss
> More help   : https://help.launchpad.net/ListHelp
>