Hello,
same issue when upgrading from 4.0.0 to 4.0.3 ping: cms-db: Temporary failure in name resolution
or ping: mysql: Temporary failure in name resolution
Dan asked me mysql logs a few weeks ago. Here are the results
Same logs between 4.0.0 and 4.0.2 version
root@s001linux03:/opt/xibo# docker-compose ps
Name Command State Ports
xibo_cms-db_1 docker-entrypoint.sh mysqld Up 3306/tcp, 33060/tcp
xibo_cms-memcached_1 docker-entrypoint.sh memca … Up 11211/tcp
xibo_cms-quickchart_1 yarn start Up 3400/tcp
xibo_cms-web_1 /entrypoint.sh Up 0.0.0.0:8080->80/tcp,:::8080->80/tcp
xibo_cms-xmr_1 docker-php-entrypoint /ent … Up 50001/tcp, 0.0.0.0:9505->9505/tcp,:::9505->9505/tcp
docker-compose logs -f cms-db (returns many lines like these)
cms-db_1 | 2023-09-11T04:53:54.536445Z 67143 [Warning] [MY-013360] [Server] Plugin mysql_native_password reported: ‘‘mysql_native_password’ is deprecated and will be removed in a future release. Please use caching_sha2_password instead’
cms-db_1 | 2023-09-11T04:53:55.136175Z 67144 [Warning] [MY-013360] [Server] Plugin mysql_native_password reported: ‘‘mysql_native_password’ is deprecated and will be removed in a future release. Please use caching_sha2_password instead’
I tried with mysqld --user=root --skip-grant-tables &
but failure again
root@9d66dd614b30:/# mysqld --user=root --skip-grant-tables &
[1] 36
root@9d66dd614b30:/# 2023-09-29T15:36:18.353276Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2023-09-29T15:36:18.355749Z 0 [Note] mysqld (mysqld 5.7.34) starting as process 36 …
2023-09-29T15:36:18.359750Z 0 [Note] InnoDB: PUNCH HOLE support available
2023-09-29T15:36:18.359774Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2023-09-29T15:36:18.359780Z 0 [Note] InnoDB: Uses event mutexes
2023-09-29T15:36:18.359786Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2023-09-29T15:36:18.359836Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2023-09-29T15:36:18.359865Z 0 [Note] InnoDB: Using Linux native AIO
2023-09-29T15:36:18.360720Z 0 [Note] InnoDB: Number of pools: 1
2023-09-29T15:36:18.361134Z 0 [Note] InnoDB: Not using CPU crc32 instructions
2023-09-29T15:36:18.364546Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2023-09-29T15:36:18.377043Z 0 [Note] InnoDB: Completed initialization of buffer pool
2023-09-29T15:36:18.380418Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2023-09-29T15:36:18.392351Z 0 [ERROR] [FATAL] InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4000!
2023-09-29 15:36:18 0x7fd8a663b740 InnoDB: Assertion failure in thread 140568481216320 in file ut0ut.cc line 921
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
15:36:18 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.
key_buffer_size=8388608
read_buffer_size=131072
max_used_connections=0
max_threads=151
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68197 K bytes of memory
Hope that’s ok; if not, decrease some variables in the equation.
Thread pointer: 0x0
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 = 0 thread_stack 0x40000
mysqld(my_print_stacktrace+0x2c)[0x55885fd004fc]
mysqld(handle_fatal_signal+0x501)[0x55885f61dff1]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7fd8a6b9c730]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b)[0x7fd8a66777bb]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x121)[0x7fd8a6662535]
mysqld(+0x6c1f13)[0x55885f5e4f13]
mysqld(+0x6c22f1)[0x55885f5e52f1]
mysqld(+0x11ab32c)[0x5588600ce32c]
mysqld(+0x11ab95e)[0x5588600ce95e]
mysqld(Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8+0x312)[0x5588600d6462]
mysqld(+0x116bce8)[0x55886008ece8]
mysqld(_Z13buf_read_pageRK9page_id_tRK11page_size_t+0x31)[0x55886008f311]
mysqld(_Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb+0x409)[0x558860063249]
mysqld(_Z31trx_rseg_get_n_undo_tablespacesPm+0x13e)[0x5588600000de]
mysqld(+0x10aed87)[0x55885ffd1d87]
mysqld(_Z34innobase_start_or_create_for_mysqlv+0x2f67)[0x55885ffd5947]
mysqld(+0xf85080)[0x55885fea8080]
mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x55)[0x55885f66fa45]
mysqld(+0xbd9326)[0x55885fafc326]
mysqld(_Z40plugin_register_builtin_and_init_core_sePiPPc+0x1dc)[0x55885fafe1fc]
mysqld(+0x6f580e)[0x55885f61880e]
mysqld(_Z11mysqld_mainiPPc+0x758)[0x55885f619c78]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7fd8a666409b]
mysqld(_start+0x2a)[0x55885f60ecba]
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.
The instructions in the link Natasha sent over are for if you’re using MySQL 5.7. I think you’re using MySQL 8.0 which we supply in the docker files.
In that case the first instruction is slightly different:
docker run --rm -ti -v /opt/xibo/shared/db:/var/lib/mysql mysql:8.0 bash
We have another case we’re looking at where the user gets the following logs running the instructions in the link, with a MySQL 8.0 container:
bash-4.4# mysqld --skip-grant-tables &
[1] 8
bash-4.4# 2023-10-02T12:21:54.620768Z 0 [Warning] [MY-011068] [Server] The syntax '--skip-host-cache' is deprecated and will be removed in a future release. Please use SET GLOBAL host_cache_size=0 instead.
2023-10-02T12:21:54.622328Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.32) starting as process 8
2023-10-02T12:21:54.631248Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2023-10-02T12:21:55Z UTC - mysqld got signal 11 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=6b049f17400f850658b2eb3ff165ec9a085d9655
Thread pointer: 0x0
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 = 0 thread_stack 0x100000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x41) [0x213de91]
/usr/sbin/mysqld(print_fatal_signal(int)+0x387) [0xfdeac7]
/usr/sbin/mysqld(handle_fatal_signal+0xa5) [0xfdeb85]
/lib64/libpthread.so.0(+0x12d00) [0x7fbe7a52bd00]
/usr/sbin/mysqld(page_cur_insert_rec_low(unsigned char*, dict_index_t*, unsigned char const*, unsigned long*, mtr_t*)+0x62e) [0x233806e]
/usr/sbin/mysqld(page_cur_parse_insert_rec(bool, unsigned char const*, unsigned char const*, buf_block_t*, dict_index_t*, mtr_t*)+0x80d) [0x233b32d]
/usr/sbin/mysqld() [0x2304d8c]
/usr/sbin/mysqld(recv_recover_page_func(bool, buf_block_t*)+0x69b) [0x23084bb]
/usr/sbin/mysqld(buf_page_io_complete(buf_page_t*, bool)+0x39f) [0x24a3f5f]
/usr/sbin/mysqld(fil_aio_wait(unsigned long)+0x166) [0x25ab476]
/usr/sbin/mysqld() [0x23def78]
/usr/sbin/mysqld(std::thread::_State_impl<std::thread::_Invoker<std::tuple<Detached_thread, void (*)(unsigned long), unsigned long> > >::_M_run()+0xb6) [0x23df956]
/lib64/libstdc++.so.6(+0xc2ba3) [0x7fbe794b9ba3]
/lib64/libpthread.so.0(+0x81da) [0x7fbe7a5211da]
/lib64/libc.so.6(clone+0x43) [0x7fbe78acfe73]
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.
Sorry but it’s correct to be running the MySQL 5.7 container here. We’re trying to upgrade MySQL 5.6 to 5.7 before running MySQL 8. Please don’t run MySQL 8 against the data at this point.
We know that’s the case because of the log line:
cms-db_1 | 2023-09-29T13:58:25.530880Z 1 [ERROR] [MY-013090] [InnoDB] Unsupported redo log format (v0). The redo log was created before MySQL 5.7.9
which tells us the database files are in MySQL 5.6 format.
The error you get comes from a change in the MySQL 5.7 containers. You need to make a small change.
mysqld --user=mysql --skip-grant-tables &
Although I think it should work as documented with the latest mysql:5.7 container, so you might instead do
docker pull mysql:5.7
to ensure you have the latest container version and then try as documented rather than with the modification shown above.
Hi,
do you have news about this issue ? Xibo is still in version 4.0.0 and i’m unable to upgrade to 4.0.1, …,4.0.6
Unable to upgrade mysql with mysql_upgrade
If you still can’t get it to work then I would take your pre-upgrade backup, dump the data with mysqldump, stop the containers, move shared/db to shared/db_old, and put your database dump as shared/backup/import.sql.
Then do the upgrade, and your backup will be loaded in to a clean MySQL database and it should all be fine from there.
Hello. Only for the purpose of replying to this thread I created account on this platform. I hope that this post would save hours of hairpulling for others.
I struggled for 2 days with fixing my issue, which looked exactly like @pp_browser . I could login to mysql DB, all pings were OK.
The magic trick that fixed my issue was adding ‘–remove-orphans’ at the end of ‘up’ command. So the magic command was:
docker-compose up -d --remove-orphans
After that - Boom! . New version installed.
An interesting fact is that, every upgrade between v3 versions were OK ( 3.3.3 → 3.3.7 → 3.3.8 → 3.3.9), but every upgrade between v3 and v4 was a failure (3.3.3 → 4.0.0 , 3.3.3 → 4.0.6 , 3.3.7 → 4.0.0 etc.).
