RT 3.8.8 upgrade stacked on database upgrade

RT Users
1

Hi all,
I went through all the documentation that I’ve found to upgrade from
3.8.8 to 4.2.11(from old server to a new one) so what I am doing is:
I am using SLES12, MariaDB 10.0.16

-Create DDBB for the rt04
MariaDB [(none)]> create database rt4;

-Load rt3 dump to the new DDBB named rt4
mysql -u root -p --default-character-set=binary rt4 < /srv/tmp/rt3.sql

-Create schema
perl etc/upgrade/upgrade-mysql-schema.pl rt4 rt_user rt_pass > queries.sql

-Load schema
mysql -u rt_user -p rt4 < queries.sql

-Make upgrade
make upgrade-database

And at this point the upgrade stops and drops an error (after filling up
the disk). I’ve got a 10G database within a 100G hard drive,

Proceed [y/N]:y
Processing 3.8.9
Now inserting data.
Processing 3.9.1
Now inserting data.
Processing 3.9.2
Now inserting data.
Processing 3.9.3
Now populating database schema.
Processing 3.9.5
Now populating database schema.
[11216] [Thu Jul 2 12:50:44 2015] [critical]: DBD::mysql::st execute
failed: Lost connection to MySQL server during query at
/root/rt-4.2.11/sbin/…/lib/RT/Handle.pm line 552.
(/root/rt-4.2.11/sbin/…/lib/RT.pm:389)
DBD::mysql::st execute failed: Lost connection to MySQL server during
query at /root/rt-4.2.11/sbin/…/lib/RT/Handle.pm line 552.
Makefile:389: recipe for target ‘upgrade-database’ failed
make: *** [upgrade-database] Error 9

The file that is taking up the space is:

#sql-ib162-2876089901.ibd nearly 80G

Those are the logs from /var/log/mysql/mysqld.log

It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
137034 K bytes of memory
Hope that’s ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong…
stack_bottom = 0x0 thread_stack 0x48000
/usr/sbin/mysqld(my_print_stacktrace+0x29)[0xb72d89]
/usr/sbin/mysqld(handle_fatal_signal+0x515)[0x71dbc5]
/lib64/libpthread.so.0(+0xf890)[0x7f1effc44890]
/lib64/libc.so.6(gsignal+0x37)[0x7f1efea5b187]
/lib64/libc.so.6(abort+0x118)[0x7f1efea5c538]
/usr/sbin/mysqld[0x9eef64]
/lib64/libpthread.so.0(+0x80a4)[0x7f1effc3d0a4]
/lib64/libc.so.6(clone+0x6d)[0x7f1efeb0b08d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
150702 14:50:45 mysqld_safe Number of processes running now: 0
150702 14:50:45 mysqld_safe mysqld restarted
150702 14:50:46 [Note] InnoDB: Using mutexes to ref count buffer pool pages
150702 14:50:46 [Note] InnoDB: The InnoDB memory heap is disabled
150702 14:50:46 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
150702 14:50:46 [Note] InnoDB: Memory barrier is not used
150702 14:50:46 [Note] InnoDB: Compressed tables use zlib 1.2.8

I would really appreciate any help on this.

Best regards.
Josep

WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.

2

Well, I’ve just realized that the schema upgrade was not needed for
moving from 3.8.8 to 4.x.x, but however I have had the same issue, the
hard drive is filling when doing:

make upgrade-databaseOn 02/07/15 14:55, Josep Manel Andrés wrote:

Hi all,
I went through all the documentation that I’ve found to upgrade from
3.8.8 to 4.2.11(from old server to a new one) so what I am doing is:
I am using SLES12, MariaDB 10.0.16

-Create DDBB for the rt04
MariaDB [(none)]> create database rt4;

-Load rt3 dump to the new DDBB named rt4
mysql -u root -p --default-character-set=binary rt4 < /srv/tmp/rt3.sql

-Create schema
perl etc/upgrade/upgrade-mysql-schema.pl rt4 rt_user rt_pass > queries.sql

-Load schema
mysql -u rt_user -p rt4 < queries.sql

-Make upgrade
make upgrade-database

And at this point the upgrade stops and drops an error (after filling up
the disk). I’ve got a 10G database within a 100G hard drive,

Proceed [y/N]:y
Processing 3.8.9
Now inserting data.
Processing 3.9.1
Now inserting data.
Processing 3.9.2
Now inserting data.
Processing 3.9.3
Now populating database schema.
Processing 3.9.5
Now populating database schema.
[11216] [Thu Jul 2 12:50:44 2015] [critical]: DBD::mysql::st execute
failed: Lost connection to MySQL server during query at
/root/rt-4.2.11/sbin/…/lib/RT/Handle.pm line 552.
(/root/rt-4.2.11/sbin/…/lib/RT.pm:389)
DBD::mysql::st execute failed: Lost connection to MySQL server during
query at /root/rt-4.2.11/sbin/…/lib/RT/Handle.pm line 552.
Makefile:389: recipe for target ‘upgrade-database’ failed
make: *** [upgrade-database] Error 9

The file that is taking up the space is:

#sql-ib162-2876089901.ibd nearly 80G

Those are the logs from /var/log/mysql/mysqld.log

It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads =
137034 K bytes of memory
Hope that’s ok; if not, decrease some variables in the equation.

Thread pointer: 0x0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong…
stack_bottom = 0x0 thread_stack 0x48000
/usr/sbin/mysqld(my_print_stacktrace+0x29)[0xb72d89]
/usr/sbin/mysqld(handle_fatal_signal+0x515)[0x71dbc5]
/lib64/libpthread.so.0(+0xf890)[0x7f1effc44890]
/lib64/libc.so.6(gsignal+0x37)[0x7f1efea5b187]
/lib64/libc.so.6(abort+0x118)[0x7f1efea5c538]
/usr/sbin/mysqld[0x9eef64]
/lib64/libpthread.so.0(+0x80a4)[0x7f1effc3d0a4]
/lib64/libc.so.6(clone+0x6d)[0x7f1efeb0b08d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
150702 14:50:45 mysqld_safe Number of processes running now: 0
150702 14:50:45 mysqld_safe mysqld restarted
150702 14:50:46 [Note] InnoDB: Using mutexes to ref count buffer pool pages
150702 14:50:46 [Note] InnoDB: The InnoDB memory heap is disabled
150702 14:50:46 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
150702 14:50:46 [Note] InnoDB: Memory barrier is not used
150702 14:50:46 [Note] InnoDB: Compressed tables use zlib 1.2.8

I would really appreciate any help on this.

Best regards.
Josep

Josep Manel Andrés (josep.andres@bsc.es)
Operations - Barcelona Supercomputing Centre
C/ Jordi Girona, 31 http://www.bsc.es
08034 Barcelona, Spain Tel: +34-93-405 42 14
e-mail: systems@bsc.es Fax: +34-93-413 77 21

WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.

3

make upgrade-database

And at this point the upgrade stops and drops an error (after filling up
the disk). I’ve got a 10G database within a 100G hard drive,
:
:
The file that is taking up the space is:

#sql-ib162-2876089901.ibd nearly 80G

Those are the logs from /var/log/mysql/mysqld.log

The web at:
http://dev.mysql.com/doc/refman/5.5/en/glossary.html#glos_ibd_file
states:
.ibd file
The data file for file-per-table tablespaces and general tablespaces.
File-per-table tablespace .idb files contain a single table and
associated index data. General tablespace .idb files may contain
table and index data for multiple tables. General tablespaces were
introduced in MySQL 5.7.6.

  The .ibd file extension does not apply to the system tablespace, 
  which consists of the ibdata files.

  If a file-per-table table is created with the DATA DIRECTORY = clause
  (in MySQL 5.6 and higher), the .ibd file is located outside the
  normal database directory, and is pointed to by a .isl file.

Look into what is making this file. Maybe that will give a clue.

I’m new at this application, but old at debugging.

/jeff
The information contained in this e-mail is for the exclusive use of the
intended recipient(s) and may be confidential, proprietary, and/or
legally privileged. Inadvertent disclosure of this message does not
constitute a waiver of any privilege. If you receive this message in
error, please do not directly or indirectly use, print, copy, forward,
or disclose any part of this message. Please also delete this e-mail
and all copies and notify the sender. Thank you.

For alternate languages please go to http://bayerdisclaimer.bayerweb.com

4

Joop wrote:

Have a look at the upgrade-articles script and see if other things might
be missing. From the above it looks like the ‘update links’ step didn’t
work out OK.

I checked the script. The Links were already done before the error.
The Transactions, failed, but my manual update did the equivalent.
The Transactions update of the AddLink was a no-op since the matching
Conditions would have matched no records.
The same for the Attributes, as it matched no records.
Looks like I am OK.

Thanks for your help.

/jeff
The information contained in this e-mail is for the exclusive use of the
intended recipient(s) and may be confidential, proprietary, and/or
legally privileged. Inadvertent disclosure of this message does not
constitute a waiver of any privilege. If you receive this message in
error, please do not directly or indirectly use, print, copy, forward,
or disclose any part of this message. Please also delete this e-mail
and all copies and notify the sender. Thank you.

For alternate languages please go to http://bayerdisclaimer.bayerweb.com