sys-libs/timezone-data and MySQL

after an upgrade of sys-libs/timezone-data is good advice to
update the
mysql timezones tables too:

# mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p
mysql

for details refer to
http://dev.mysql.com/doc/refman/5.0/en/time-zone-su
pport.html

-- 
gentoo-servergentoo.org mailing list

> after an upgrade of sys-libs/timezone-data is good
advice to update the
> mysql timezones tables too:
>
> # mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u
root -p mysql
>
> for details refer to
> http://dev.mysql.com/doc/refman/5.0/en/time-zone-su
pport.html

also - contrary to most Distro installation docs (which
includes Gentoo
 ):

In those docs, /etc/localtime ought to be copied from
/usr/share/timezone/XX/YY
Personally, I rather set a symlink than copy the file...
Has the following advantages:
 - It's clearly visible what's the configured timezone (by
simply reading
the link text  )
 - updates to timezone-data update system's timezone
automagically

Drawbacks:
  according to FHS /usr may be a remote filesystem, but
/etc/localtime has
to exist during boot.

Christian

-- 
gentoo-servergentoo.org mailing list

Hi!

On Fri, Dec 01, 2006 at 10:30:15AM +0100, Francesco Riosa
wrote:
> after an upgrade of sys-libs/timezone-data is good
advice to update the
> mysql timezones tables too:

Hmm... What can be affected by this? How MySQL use timezone
information,
which part of timezone information may change (and so
require updates of
sys-libs/timezone-data) and why these changes may be
important for MySQL?

-- 
			WBR, Alex.
-- 
gentoo-servergentoo.org mailing list

Hi!

On Fri, Dec 01, 2006 at 01:53:05PM +0100, Christian Bricart
wrote:
> Drawbacks:
>   according to FHS /usr may be a remote filesystem, but
/etc/localtime has
> to exist during boot.

Can anybody in _this_ maillist confirm importance of
"remote /usr" support?

In my experience remote /usr is very rare case nowadays and
supporting it
"by default" result in few very uncomfortable
things - in addition to
/etc/localtime example I can add grep ebuild which compile
grep without
perl regexp support (only because libperl is in /usr while
grep is in /).

-- 
			WBR, Alex.
-- 
gentoo-servergentoo.org mailing list

On Fri, 8 Dec 2006, Alex Efros wrote:

> On Fri, Dec 01, 2006 at 01:53:05PM +0100, Christian
Bricart wrote:
> > Drawbacks:
> >   according to FHS /usr may be a remote
filesystem, but /etc/localtime has
> > to exist during boot.
>
> Can anybody in _this_ maillist confirm importance of
"remote /usr" support?
>
> In my experience remote /usr is very rare case nowadays
and supporting it
> "by default" result in few very uncomfortable
things - in addition to
> /etc/localtime example I can add grep ebuild which
compile grep without
> perl regexp support (only because libperl is in /usr
while grep is in /).

I use an NFS mounted /usr file system extensively, although
not on gentoo
systems - I've not got any deployments running gentoo that
are large
enough to make it worth the effort.


-Ronan
-- 
gentoo-servergentoo.org mailing list

Hi!

I notice you are one of authors for Gentoo's MySQL upgrade
guide
    http
://www.gentoo.org/doc/en/mysql-upgrading.xml
and I've few questions about it.

    # MYSQL --execute="FLUSH TABLES WITH READ
LOCK;"
    ...
    # MYSQL --execute="UNLOCK TABLES;"

AFAIK MySQL drop any locks when connection closes, so you
probably need to
open MySQL client in another console and run FLUSH
TABLES/UNLOCK TABLES
there while executing tar in first console between these
commands.

    # mysql_upgrade_shell --user=root
--password='your_password' 
	 --protocol=tcp --datadir="$"

In original MySQL upgrade documentation they recommend to
run mysql_upgrade
program and there is nothing about mysql_upgrade_shell
script.
AFAIK mysql_upgrade_shell is older version of this program
(mysql_upgrade
program was added because there no bash to execute
mysql_upgrade_shell
script on Win32).
So, what's better to run - mysql_upgrade_shell or
mysql_upgrade? Or there
no difference between them now?

-- 
			WBR, Alex.
-- 
gentoo-servergentoo.org mailing list

Hi!

On Fri, Dec 08, 2006 at 01:45:31AM +0200, Alex Efros wrote:
>     # mysql_upgrade_shell --user=root
--password='your_password' 
> 	 --protocol=tcp --datadir="$"
> 
> In original MySQL upgrade documentation they recommend
to run mysql_upgrade
> program and there is nothing about mysql_upgrade_shell
script.
> AFAIK mysql_upgrade_shell is older version of this
program (mysql_upgrade
> program was added because there no bash to execute
mysql_upgrade_shell
> script on Win32).
> So, what's better to run - mysql_upgrade_shell or
mysql_upgrade? Or there
> no difference between them now?

BTW, I got error while running mysql_upgrade_shell:

---cut---
# mysql_upgrade_shell --user=root --password='MYPASS'
--protocol=tcp --datadir="$"
This script updates all the mysql privilege tables to be
usable by
MySQL 4.0 and above.

This is needed if you want to use the new GRANT functions,
CREATE AGGREGATE FUNCTION, stored procedures, or
more secure passwords in 4.1

Got a failure from command:
cat /usr/share/mysql/mysql_fix_privilege_tables.sql |
/usr/bin/mysql --no-defaults --force --user=root
--host=localhost --password=MYPASS --database=mysql
Please check the above output and try again.

Running the script with the --verbose option may give you
some information
of what went wrong.

If you get an 'Access denied' error, you should run this
script again and
give the MySQL root user password as an argument with the
--password= option
---cut---

As you see, there no "above output", so I've tried
to run failed command
manually. And got strange output with some errors:

---cut---
ERROR 1060 (42S21) at line 22: Duplicate column name
'File_priv'
hadGrantPriv:=1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
ERROR 1060 (42S21) at line 28: Duplicate column name
'Grant_priv'
ERROR 1060 (42S21) at line 29: Duplicate column name
'Grant_priv'
ERROR 1060 (42S21) at line 30: Duplicate column name
'Grant_priv'
ERROR 1060 (42S21) at line 41: Duplicate column name
'ssl_type'
ERROR 1146 (42S02) at line 67: Table 'mysql.procs_priv'
doesn't exist
ERROR 1146 (42S02) at line 68: Table 'mysql.procs_priv'
doesn't exist
ERROR 1146 (42S02) at line 70: Table 'mysql.procs_priv'
doesn't exist
ERROR 1146 (42S02) at line 72: Table 'mysql.procs_priv'
doesn't exist
ERROR 1054 (42S22) at line 94: Unknown column 'Type' in
'columns_priv'
ERROR 1060 (42S21) at line 100: Duplicate column name 'type'
hadShowDbPriv:=1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
ERROR 1060 (42S21) at line 110: Duplicate column name
'Show_db_priv'
ERROR 1060 (42S21) at line 127: Duplicate column name
'max_questions'
ERROR 1060 (42S21) at line 137: Duplicate column name
'Create_tmp_table_priv'
ERROR 1060 (42S21) at line 140: Duplicate column name
'Create_tmp_table_priv'
ERROR 1061 (42000) at line 145: Duplicate key name 'Grantor'
ERROR 1054 (42S22) at line 247: Unknown column
'Create_view_priv' in 'where clause'
ERROR 1054 (42S22) at line 277: Unknown column
'Create_routine_priv' in 'where clause'
ERROR 1054 (42S22) at line 313: Unknown column
'Create_user_priv' in 'where clause'
---cut---

Running mysql_upgrade result in similar errors but looks
like it stop on
first error:

---cut---
# mysql_upgrade -p -v --basedir=/usr
Enter password: 
mysql_upgrade already done for this version
ERROR 1060 (42S21) at line 22: Duplicate column name
'File_priv'
---cut---

-- 
			WBR, Alex.
-- 
gentoo-servergentoo.org mailing list

>Hi!
>
>On Fri, Dec 01, 2006 at 10:30:15AM +0100, Francesco
Riosa wrote:
>> > after an upgrade of sys-libs/timezone-data is
good advice to update the
>> > mysql timezones tables too:
>
>Hmm... What can be affected by this? How MySQL use
timezone information,
>which part of timezone information may change (and so
require updates of
>sys-libs/timezone-data) and why these changes may be
important for MySQL?

I did prepared a (possibly) decent answer then my MUA
decided to crash and
destroy it, must be something karmik so here there is the
shortened version:

sys-libs/timezone-data can change daylight saving switching
day, also leap
seconds, time mangling/conversion stuff in general.
Strictly speaking you need to update timezone-data to have a
sane system,
think also at "cron"ed scripts.

[TMZ] leave make suppose that most of [DTM] functions are
affected. At least
if your server timezone is changed in the latest
timezone-data release.

Running replication? Then [REP] will tell you subtly things
that can happen
to timestamps and UPDATE/INSERT using date functions if the
servers are not
in sync i.e. using the same timezone data.

Clustering? No idea and I don't even want to try.

Regards,
Francesco

[TMZ] http://dev.mysql.com/doc/refman/5.0/en/time-zone-su
pport.html
[REP] http://dev.mysql.com/doc/refman/5.0/en/replicati
on-features.html
[DTM] http://dev.mysql.com/doc/refman/5.0/en/date-a
nd-time-functions.html

-- 
gentoo-servergentoo.org mailing list

Alex Efros ha scritto:
> Hi!
>
> I notice you are one of authors for Gentoo's MySQL
upgrade guide
>     http
://www.gentoo.org/doc/en/mysql-upgrading.xml
> and I've few questions about it.
>
>     # MYSQL --execute="FLUSH TABLES WITH READ
LOCK;"
>     ...
>     # MYSQL --execute="UNLOCK TABLES;"
>
> AFAIK MySQL drop any locks when connection closes, so
you probably need to
> open MySQL client in another console and run FLUSH
TABLES/UNLOCK TABLES
> there while executing tar in first console between
these commands.
>
>     # mysql_upgrade_shell --user=root
--password='your_password' 
> 	 --protocol=tcp --datadir="$"
>   
Verified, docs need to be updated, I'm planning to do a
bunch of things
next three days on mysql this will be one.
> In original MySQL upgrade documentation they recommend
to run mysql_upgrade
> program and there is nothing about mysql_upgrade_shell
script.
> AFAIK mysql_upgrade_shell is older version of this
program (mysql_upgrade
> program was added because there no bash to execute
mysql_upgrade_shell
> script on Win32).
> So, what's better to run - mysql_upgrade_shell or
mysql_upgrade? Or there
> no difference between them now?
>   
mysql_upgrade_shell  has survived better to my test but I
should redo
those now probably mysql_upgrade is better maintained.

-- 
gentoo-servergentoo.org mailing list