Mensaje archivado #866 de la Lista ecs-isp@2rosenthals.com

De: "Massimo S." <ecs-isp@2rosenthals.com> Encabezados Completos
Mensaje no decodificado
Asunto: Re: [eCS-ISP] mysql upgrade 5.1.73 -> 5.6.51
Fecha: Tue, 27 Aug 2024 21:29:38 +0200
Para: eCS ISP Mailing List <ecs-isp@2rosenthals.com>



Il 27/08/2024 21:14, Massimo S. ha scritto:


Il 10/08/2023 00:19, Steven Levine ha scritto:
In <list-7611426@2rosenthals.com>, on 08/09/23
    at 12:09 PM, "Massimo S." <ecs-isp@2rosenthals.com> said:

Hi all,

Here's the mysql upgrade procedure that worked for me

==============================
== mysql_upgrade 5.1 -> 5.6 ==
==============================

  - Tested with mysqld
      Ver 5.1.73 for pc-os2-emx on i386 (Source distribution)
    and
      Ver 5.6.51 for OS2 on i386 (Source distribution)

  - The following assumes
      5.6 datadir will be /data/mysql56
      5.1 datadir is /data/mysql51
      innodb_data_home_dir is /data/mysql56-data/innodb
  - Use names that match your setup

  - Open session with current directory set to 5.6 bin directory
    Run binaries from the directory

  - Verify my.cnf is 5.6 compatible
    Edit as needed to protect/hide 5.1 data

  - Create /data/mysql56
  - Create /data/mysql56/mysql
  - Create /data/mysql56/innodb
  - Copy /data/mysql51/mysql to /data/mysql56/mysql
  - Run
      mysqld --console
    The server should start
    There will be warnings
  - Run
      mysql_upgrade
    The server may crash
  - If the server crashes, run
      mysqld --console
    to restart the server
    There will be warnings
    Run
      mysql_upgrade
    to retry the upgrade
    The upgrade should run without errors
    if not get help

  - Copy the rest of the 5.1 databases to /data/mysql56
  - Run
      mysql_upgrade --force
    to upgrade these databases
    The upgrade should run without errors
    If not get help

  - Run
      mysqlcheck --all-databases
    to cross-check upgrade results

  - Check /data/mysql56/mysql_upgrade_info
    It should contain 5.6.51

The logs imply that, at least in my case, only the mysql database needed
unusual modifications.  The log output for all the other databases and
tables reported OK with no additional messages or warnings.

Steven

Hi all,

i still have to upgrade to mysql 5.6.51, i'm doing some tests with mysql56 another VM
(for another i mean not the one where mysql 5.1.73 is running in production)

since 2 webmails (roundcube) and a web server (AMP) use my mysqlD (5.1.73)
i have to take extreme precautions, since i guess that i will have no possibility
of fall back to 5.1.73 after the upgrade (surely not after days or hours of uptime)

when i run mysql_upgrade i get a number of "exits" of mysqlD and i ran again
the upgrade with the --force option, ok, but i get a number of these:

2024-08-27 19:45:32 8664 [Warning] InnoDB: Cannot open table rcube/cache_shared
2024-08-27 19:45:32 8664 [Warning] InnoDB: Cannot open table rcube2/cache_index

etc. etc.

i followed Steven instructions and i first copied to mysql\data
only the old (5173) mysql directory
but *i've not copied also the content in the mysql\data directory)
i mean:

ib_logfile0     5.120K     10/08/23
ib_logfile1    5.120K    08/08/23
ibdata1       206.848K 10/08/23


is this good, or am i wrong?

and should i ignore those Warnings InnoDB cannot open table etc..?

thanks

massimo

other stuff running mysqlD

2024-08-27 20:48:08 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details). 2024-08-27 20:48:08 0 [Note] --secure-file-priv is set to NULL. Operations related to importing and exporting data are disabled

about TIMESTAMP warning i put:  explicit_defaults_for_timestamp = 1
in my.cnf, but is this good on /2 OS?

about "[Note] --secure-file-priv is set to NULL..."
should i ignore it?

if it mean i can't import or export a DB to mysql, this is a trouble for me

massimo

Suscribirse: Todos, Compendio, Indice.
Desuscribirse
Correo al dueño de la Lista