Re: [rt-users] RT 3.8.8 upgrade stacked on database upgrade
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
Re: [rt-users] RT 3.8.8 upgrade stacked on database upgrade
On 02/07/15 14:55, Josep Manel Andr?s wrote: > 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
Re: [rt-users] RT 3.8.8 upgrade stacked on database upgrade
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-database On 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.and...@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: syst...@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. http://www.bsc.es/disclaimer
[rt-users] RT 3.8.8 upgrade stacked on database upgrade
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. http://www.bsc.es/disclaimer