一键部署时 MySQL 启动异常,求救

你好,请使用下面命令看看日志

# 替换PodName 为 mysql  的pod名称
 kubectl logs -n c7n-system <PodName>

kubectl get pv
# 上面命令查找mysql 的 pv,然后再使用下面命令查看数据挂载的目录,进到目录中删除里面所有数据
kubectl describe pv pvc-xxxxxxxxx
# 重启mysql
kubectl delete po -n c7n-system mysql-xxxxxxx

都尝试过,把整个k8s 和pv都删除,pvc 也删除了 还是不可以

2020-08-28T07:42:59.924095Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2020-08-28T07:42:59.928493Z 0 [Note] mysqld (mysqld 5.7.23) starting as process 1 ...
2020-08-28T07:42:59.941175Z 0 [Note] InnoDB: PUNCH HOLE support available
2020-08-28T07:42:59.941208Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2020-08-28T07:42:59.941213Z 0 [Note] InnoDB: Uses event mutexes
2020-08-28T07:42:59.941216Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2020-08-28T07:42:59.941220Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.3
2020-08-28T07:42:59.941223Z 0 [Note] InnoDB: Using Linux native AIO
2020-08-28T07:42:59.942381Z 0 [Note] InnoDB: Number of pools: 1
2020-08-28T07:42:59.942524Z 0 [Note] InnoDB: Using CPU crc32 instructions
2020-08-28T07:42:59.944833Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2020-08-28T07:42:59.954859Z 0 [Note] InnoDB: Completed initialization of buffer pool
2020-08-28T07:42:59.957635Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2020-08-28T07:42:59.982674Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2020-08-28T07:42:59.986009Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 49472
2020-08-28T07:43:00.026902Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 2588005
2020-08-28T07:43:00.031323Z 0 [Note] InnoDB: Database was not shutdown normally!
2020-08-28T07:43:00.031341Z 0 [Note] InnoDB: Starting crash recovery.
2020-08-28T07:43:00.054828Z 0 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
2020-08-28T07:43:00.586670Z 0 [Note] InnoDB: Apply batch completed
2020-08-28T07:43:00.693553Z 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2020-08-28T07:43:00.693582Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2020-08-28T07:43:00.695589Z 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2020-08-28T07:43:00.757452Z 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2020-08-28T07:43:00.759228Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
2020-08-28T07:43:00.759250Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active.
2020-08-28T07:43:00.759866Z 0 [Note] InnoDB: Waiting for purge to start
2020-08-28T07:43:00.810116Z 0 [Note] InnoDB: 5.7.23 started; log sequence number 2588005
2020-08-28T07:43:00.810695Z 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2020-08-28T07:43:00.810753Z 0 [ERROR] InnoDB: Cannot open '/var/lib/mysql/ib_buffer_pool' for reading: No such file or directory
2020-08-28T07:43:00.810775Z 0 [Note] Plugin 'FEDERATED' is disabled.
2020-08-28T07:43:00.854618Z 0 [Warning] Failed to set up SSL because of the following SSL library error: SSL context is not usable without certificate and private key
2020-08-28T07:43:00.855149Z 0 [Note] Server hostname (bind-address): '*'; port: 3306
2020-08-28T07:43:00.855208Z 0 [Note] IPv6 is available.
2020-08-28T07:43:00.855244Z 0 [Note]   - '::' resolves to '::';
2020-08-28T07:43:00.855276Z 0 [Note] Server socket created on IP: '::'.
2020-08-28T07:43:00.859360Z 0 [Warning] Insecure configuration for --pid-file: Location '/var/run/mysqld' in the path is accessible to all OS users. Consider choosing a different directory.
2020-08-28T07:43:00.863874Z 0 [Warning] 'user' entry 'root@localhost' ignored in --skip-name-resolve mode.
2020-08-28T07:43:00.863925Z 0 [Warning] 'user' entry 'mysql.session@localhost' ignored in --skip-name-resolve mode.
2020-08-28T07:43:00.863937Z 0 [Warning] 'user' entry 'mysql.sys@localhost' ignored in --skip-name-resolve mode.
2020-08-28T07:43:00.863961Z 0 [Warning] 'db' entry 'performance_schema mysql.session@localhost' ignored in --skip-name-resolve mode.
2020-08-28T07:43:00.863966Z 0 [Warning] 'db' entry 'sys mysql.sys@localhost' ignored in --skip-name-resolve mode.
2020-08-28T07:43:00.863975Z 0 [Warning] 'proxies_priv' entry '@ root@localhost' ignored in --skip-name-resolve mode.
2020-08-28T07:43:00.869256Z 0 [Warning] 'tables_priv' entry 'user mysql.session@localhost' ignored in --skip-name-resolve mode.
2020-08-28T07:43:00.869278Z 0 [Warning] 'tables_priv' entry 'sys_config mysql.sys@localhost' ignored in --skip-name-resolve mode.
2020-08-28T07:43:00.944338Z 0 [Note] Event Scheduler: Loaded 0 events
2020-08-28T07:43:00.944520Z 0 [Note] mysqld: ready for connections.
Version: '5.7.23'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  MySQL Community Server (GPL)
2020-08-28T07:43:01.759923Z 0 [ERROR] [FATAL] InnoDB: fsync() returned EIO, aborting.
2020-08-28 15:43:01 0x7f72b6ffd700  InnoDB: Assertion failure in thread 140130673219328 in file ut0ut.cc line 942
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.
07:43:01 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=1500
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 = 604254 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)[0x564d4a96da6c]
mysqld(handle_fatal_signal+0x479)[0x564d4a299709]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7f72e8d740c0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7f72e7500fff]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f72e750242a]
mysqld(+0x628c7b)[0x564d4a26fc7b]
mysqld(_ZN2ib5fatalD1Ev+0x12d)[0x564d4ab3d07d]
mysqld(_Z18os_file_flush_funci+0x1e5)[0x564d4aa2c455]
mysqld(_Z9fil_flushm+0x248)[0x564d4abf1dd8]
mysqld(_Z15log_write_up_tomb+0xb51)[0x564d4aa00ff1]
mysqld(_Z29log_buffer_sync_in_backgroundb+0x10e)[0x564d4aa01e2e]
mysqld(srv_master_thread+0xac9)[0x564d4aadfe39]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7494)[0x7f72e8d6a494]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f72e75b6acf]
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.

通过删除目录文件,删除pod 最终是这样的结果

你好,这个问题解决了吗 我也遇到了