openstack 重启mysql_突然断电导致mariadb数据库无法启动（openstack 命令无法使用）...
openstack是通過rdo?openstack-allinone一鍵部署的單機模式。
因為突然斷掉導致在物理機啟動后無法掛載/srv/loopback-device/swiftloopback設備，該設備已經丟失，目前沒找到解決辦法
只能先注釋：
[root@xc-jdsq ~(keystone_admin)]# tail -1 /etc/fstab
#/srv/loopback-device/swiftloopback ? ? /srv/node/swiftloopback ext4 ? ?noatime,nodiratime,nobarrier,loop,user_xattr ? ?0 ? ? ? 0
啟動服務器后產看實例報錯：
[root@xc-jdsq ~]# . keystonerc_admin
[root@xc-jdsq ~(keystone_admin)]# nova list
0000 ? ERROR (InternalServerError): Internal Server Error (HTTP 500)
[root@xc-jdsq ~(keystone_admin)]# openstack server list
Internal Server Error (HTTP 500)
但是實例在正常運行：
[root@xc-jdsq ~(keystone_admin)]# virsh list
Id ? ?Name ? ? ? ? ? ? ? ? ? ? ? ? ? State
----------------------------------------------------
1 ? ? instance-0000001e ? ? ? ? ? ? ?running
3 ? ? instance-0000001a ? ? ? ? ? ? ?running
4 ? ? instance-0000001b ? ? ? ? ? ? ?running
5 ? ? instance-00000019 ? ? ? ? ? ? ?running
看一下nova-api的日志：
[root@xc-jdsq ~(keystone_admin)]# tailf /var/log/nova/nova-api.log
2020-06-16 09:07:13.851 6460 ERROR nova.api.metadata.handler ? ? return self.dbapi.connect(*cargs, **cparams)
2020-06-16 09:07:13.851 6460 ERROR nova.api.metadata.handler ? File "/usr/lib/python2.7/site-packages/pymysql/__init__.py", line 94, in Connect
2020-06-16 09:07:13.851 6460 ERROR nova.api.metadata.handler ? ? return Connection(*args, **kwargs)
2020-06-16 09:07:13.851 6460 ERROR nova.api.metadata.handler ? File "/usr/lib/python2.7/site-packages/pymysql/connections.py", line 327, in __init__
2020-06-16 09:07:13.851 6460 ERROR nova.api.metadata.handler ? ? self.connect()
2020-06-16 09:07:13.851 6460 ERROR nova.api.metadata.handler ? File "/usr/lib/python2.7/site-packages/pymysql/connections.py", line 629, in connect
2020-06-16 09:07:13.851 6460 ERROR nova.api.metadata.handler ? ? raise exc
2020-06-16 09:07:13.851 6460 ERROR nova.api.metadata.handler DBConnectionError: (pymysql.err.OperationalError) (2003, "Can't connect to MySQLserver on '1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?92.168.1.99' ([Errno 111] ECONNREFUSED)") (Background on this error at: http://sqlalche.me/e/e3q8)
2020-06-16 09:07:13.851 6460 ERROR nova.api.metadata.handler
好像是數據庫的問題：
[root@xc-jdsq ~(keystone_admin)]# journalctl -xe
Jun 16 09:28:56 xc-jdsq systemd[1]: Unit mariadb.service entered failed state.
Jun 16 09:28:56 xc-jdsq systemd[1]: mariadb.service failed.
ESCOC
l/mysql.sock exists.
lib/mysql/mysql.sock, which means it is a garbage, so it will be removed automatically.
bably initialized in /var/lib/mysql already, nothing is done.
, make sure the /var/lib/mysql is empty before running mysql-prepare-db-dir.
n 'open_files_limit': unsigned value 18446744073709551615 adjusted to 4294967295
exec/mysqld (mysqld 10.3.10-MariaDB) starting as process 7401 ...
not increase number of max_open_files to more than 1024 (request: 8127)
ed limits: max_open_files: 1024 ?max_connections: 594 (was 4096) ?table_cache: 200 (was 2000)
rsync SST method requires wsrep_cluster_address to be configured on startup.
ode=killed, status=6/ABRT
erver.
te.
ESCOD
Jun 16 09:28:51 xc-jdsq container-server[2035]: 0 successes, 1 failures
Jun 16 09:28:51 xc-jdsq container-server[2035]: diff:0 diff_capped:0 empty:0 hashmatch:0 no_change:0 remote_merge:0 rsync:0 ts_repl:0
Jun 16 09:28:52 xc-jdsq swift[2192]: Account HEAD returning 503 for [] (txn: tx65f72d5953c24804b99a7-005ee82054)
Jun 16 09:28:52 xc-jdsq object-expirer[2192]: Unhandled exception: #012Traceback (most recent call last):#012 ?File "/usr/lib/python2.7/site-packages/s
Jun 16 09:28:54 xc-jdsq object-server[1890]: Starting object reconstruction pass.
Jun 16 09:28:54 xc-jdsq object-server[1890]: Nothing reconstructed for 0.000771045684814 seconds.
Jun 16 09:28:54 xc-jdsq object-server[1890]: Object reconstruction complete. (0.00 minutes)
Jun 16 09:28:55 xc-jdsq systemd[1]: mariadb.service holdoff time over, scheduling restart.
Jun 16 09:28:55 xc-jdsq systemd[1]: Stopped MariaDB 10.3 database server.
-- Subject: Unit mariadb.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit mariadb.service has finished shutting down.
Jun 16 09:28:55 xc-jdsq systemd[1]: Starting MariaDB 10.3 database server...
-- Subject: Unit mariadb.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit mariadb.service has begun starting up.
Jun 16 09:28:55 xc-jdsq mysql-check-socket[7327]: Socket file /var/lib/mysql/mysql.sock exists.
Jun 16 09:28:55 xc-jdsq mysql-check-socket[7327]: No process is using /var/lib/mysql/mysql.sock, which means it is a garbage, so it will be removed aut
Jun 16 09:28:55 xc-jdsq mysql-prepare-db-dir[7356]: Database MariaDB is probably initialized in /var/lib/mysql already, nothing is done.
Jun 16 09:28:55 xc-jdsq mysql-prepare-db-dir[7356]: If this is not the case, make sure the /var/lib/mysql is empty before running mysql-prepare-db-dir.
Jun 16 09:28:55 xc-jdsq mysqld[7401]: 2020-06-16 ?9:28:55 0 [Warning] option 'open_files_limit': unsigned value 18446744073709551615 adjusted to 429496
Jun 16 09:28:55 xc-jdsq mysqld[7401]: 2020-06-16 ?9:28:55 0 [Note] /usr/libexec/mysqld (mysqld 10.3.10-MariaDB) starting as process 7401 ...
Jun 16 09:28:55 xc-jdsq mysqld[7401]: 2020-06-16 ?9:28:55 0 [Warning] Could not increase number of max_open_files to more than 1024 (request: 8127)
Jun 16 09:28:55 xc-jdsq mysqld[7401]: 2020-06-16 ?9:28:55 0 [Warning] Changed limits: max_open_files: 1024 ?max_connections: 594 (was 4096) ?table_cach
Jun 16 09:28:55 xc-jdsq mysqld[7401]: 2020-06-16 ?9:28:55 0 [ERROR] WSREP: rsync SST method requires wsrep_cluster_address to be configured on startup.
Jun 16 09:28:56 xc-jdsq systemd[1]: mariadb.service: main process exited, code=killed, status=6/ABRT
Jun 16 09:28:56 xc-jdsq systemd[1]: Failed to start MariaDB 10.3 database server.
-- Subject: Unit mariadb.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit mariadb.service has failed.
--
-- The result is failed.
看一下數據庫服務的狀態：
[root@xc-jdsq ~(keystone_admin)]# systemctl status mariadb -l
● mariadb.service - MariaDB 10.3 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
Active: activating (auto-restart) (Result: signal) since Tue 2020-06-16 09:29:48 CST; 4s ago
Docs: man:mysqld(8)
https://mariadb.com/kb/en/library/systemd/
Process: 19759 ExecStartPost=/usr/libexec/mysql-check-upgrade (code=exited, status=0/SUCCESS)
Process: 8791 ExecStart=/usr/libexec/mysqld --basedir=/usr $MYSQLD_OPTS $_WSREP_NEW_CLUSTER (code=killed, signal=ABRT)
Process: 8747 ExecStartPre=/usr/libexec/mysql-prepare-db-dir %n (code=exited, status=0/SUCCESS)
Process: 8717 ExecStartPre=/usr/libexec/mysql-check-socket (code=exited, status=0/SUCCESS)
Main PID: 8791 (code=killed, signal=ABRT)
Status: "Starting final batch to recover 4 pages from redo log"
Tasks: 0
Memory: 368.0K
CGroup: /system.slice/mariadb.service
Jun 16 09:29:48 xc-jdsq systemd[1]: Failed to start MariaDB 10.3 database server.
Jun 16 09:29:48 xc-jdsq systemd[1]: Unit mariadb.service entered failed state.
Jun 16 09:29:48 xc-jdsq systemd[1]: mariadb.service failed.
這個code=killed, signal=ABRT看不懂
看一下mariadb的日志：
[root@xc-jdsq ~(keystone_admin)]# tailf /var/log/mariadb/mariadb.log
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x0):
Connection ID (thread ID): 1
Status: NOT_KILLED
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_co ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ndition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,se ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? mijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? =on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? _keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on
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.
2020-06-16 ?9:43:36 0 [Warning] You need to use --log-bin to make --binlog-format work.
2020-06-16 ?9:43:36 0 [Note] InnoDB: Using Linux native AIO
2020-06-16 ?9:43:36 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2020-06-16 ?9:43:36 0 [Note] InnoDB: Uses event mutexes
2020-06-16 ?9:43:36 0 [Note] InnoDB: Compressed tables use zlib 1.2.7
2020-06-16 ?9:43:36 0 [Note] InnoDB: Number of pools: 1
2020-06-16 ?9:43:36 0 [Note] InnoDB: Using SSE2 crc32 instructions
2020-06-16 ?9:43:36 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2020-06-16 ?9:43:37 0 [Note] InnoDB: Completed initialization of buffer pool
2020-06-16 ?9:43:37 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpr ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? iority().
2020-06-16 ?9:43:37 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=2352300158
2020-06-16 ?9:43:37 0 [Note] InnoDB: Starting final batch to recover 4 pages from redo log.
2020-06-16 ?9:43:37 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2020-06-16 ?9:43:37 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2020-06-16 ?9:43:37 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2020-06-16 ?9:43:37 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2020-06-16 ?9:43:37 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2020-06-16 ?9:43:37 0 [Note] InnoDB: Waiting for purge to start
2020-06-16 09:43:37 0x7f50177fe700 ?InnoDB: Assertion failure in file /builddir/build/BUILD/mariadb-10.3.10/storage/innobase/include/fut0lst.ic line 85
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
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: https://mariadb.com/kb/en/library/xtradbinnodb-recovery-modes/
InnoDB: about forcing recovery.
200616 ?9:43:37 [ERROR] 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.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.3.10-MariaDB
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=0
max_threads=4098
thread_count=4
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 8946935 K ?bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x7f50080009a8
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 = 0x7f50177fdbf0 thread_stack 0x40000
/usr/libexec/mysqld(my_print_stacktrace+0x2e)[0x55f569fd179e]
/usr/libexec/mysqld(handle_fatal_signal+0x357)[0x55f569a5a6e7]
sigaction.c:0(__restore_rt)[0x7f504aa6c630]
:0(__GI_raise)[0x7f5048d4e387]
:0(__GI_abort)[0x7f5048d4fa78]
2020-06-16 ?9:43:37 0 [Note] InnoDB: 10.3.10 started; log sequence number 2352303796; transaction id 13955429
2020-06-16 ?9:43:37 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
/usr/libexec/mysqld(+0x4c9b14)[0x55f5697a5b14]
/usr/libexec/mysqld(+0x4c9926)[0x55f5697a5926]
/usr/libexec/mysqld(+0xa81b05)[0x55f569d5db05]
/usr/libexec/mysqld(+0xa8312f)[0x55f569d5f12f]
/usr/libexec/mysqld(+0xa83a90)[0x55f569d5fa90]
/usr/libexec/mysqld(+0xa66ec2)[0x55f569d42ec2]
pthread_create.c:0(start_thread)[0x7f504aa64ea5]
/lib64/libc.so.6(clone+0x6d)[0x7f5048e168dd]
我菜鳥一個也看不懂數據庫
之后貌似錯誤又變了：
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_co ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ndition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,se ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? mijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? =on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? _keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on
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.
2020-06-16 10:05:27 0 [Warning] You need to use --log-bin to make --binlog-format work.
2020-06-16 10:05:27 0 [Note] InnoDB: Using Linux native AIO
2020-06-16 10:05:27 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2020-06-16 10:05:27 0 [Note] InnoDB: Uses event mutexes
2020-06-16 10:05:27 0 [Note] InnoDB: Compressed tables use zlib 1.2.7
2020-06-16 10:05:27 0 [Note] InnoDB: Number of pools: 1
2020-06-16 10:05:27 0 [Note] InnoDB: Using SSE2 crc32 instructions
2020-06-16 10:05:27 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2020-06-16 10:05:27 0 [Note] InnoDB: Completed initialization of buffer pool
2020-06-16 10:05:27 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpr ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? iority().
2020-06-16 10:05:27 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=2352300158
2020-06-16 10:05:27 0 [Note] InnoDB: Starting final batch to recover 4 pages from redo log.
2020-06-16 10:05:28 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2020-06-16 10:05:28 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2020-06-16 10:05:28 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2020-06-16 10:05:28 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2020-06-16 10:05:28 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2020-06-16 10:05:28 0 [Note] InnoDB: 10.3.10 started; log sequence number 2352303796; transaction id 13955429
2020-06-16 10:05:28 0x7f4c29ffb700 ?InnoDB: Assertion failure in file /builddir/build/BUILD/mariadb-10.3.10/storage/innobase/include/fut0lst.ic line 85
InnoDB: Failing assertion: addr.page == FIL_NULL || addr.boffset >= FIL_PAGE_DATA
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
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: https://mariadb.com/kb/en/library/xtradbinnodb-recovery-modes/
InnoDB: about forcing recovery.
200616 10:05:28 [ERROR] 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.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.3.10-MariaDB
key_buffer_size=16777216
read_buffer_size=131072
max_used_connections=0
max_threads=4098
thread_count=4
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 8946935 K ?bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x7f4c1c0009a8
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...
2020-06-16 10:05:28 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
stack_bottom = 0x7f4c29ffabf0 thread_stack 0x40000
/usr/libexec/mysqld(my_print_stacktrace+0x2e)[0x55e61bbf879e]
/usr/libexec/mysqld(handle_fatal_signal+0x357)[0x55e61b6816e7]
2020-06-16 10:05:28 0 [Note] Plugin 'FEEDBACK' is disabled.
2020-06-16 10:05:28 0 [Note] Recovering after a crash using tc.log
2020-06-16 10:05:28 0 [Note] Starting crash recovery...
2020-06-16 10:05:28 0 [Note] Crash recovery finished.
sigaction.c:0(__restore_rt)[0x7f4c54eee630]
2020-06-16 10:05:28 0 [Warning] Failed to setup SSL
2020-06-16 10:05:28 0 [Warning] SSL error: SSL_CTX_set_default_verify_paths failed
2020-06-16 10:05:28 0 [Warning] SSL error: error:02001002:system library:fopen:No such file or directory
2020-06-16 10:05:28 0 [Warning] SSL error: error:2006D080:BIO routines:BIO_new_file:no such file
2020-06-16 10:05:28 0 [Warning] SSL error: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib
2020-06-16 10:05:28 0 [Note] Server socket created on IP: '0.0.0.0'.
:0(__GI_raise)[0x7f4c531d0387]
:0(__GI_abort)[0x7f4c531d1a78]
2020-06-16 10:05:28 0 [Note] Reading of all Master_info entries succeded
2020-06-16 10:05:28 0 [Note] Added new Master_info '' to hash table
2020-06-16 10:05:28 0 [Note] /usr/libexec/mysqld: ready for connections.
Version: '10.3.10-MariaDB' ?socket: '/var/lib/mysql/mysql.sock' ?port: 3306 ?MariaDB Server
/usr/libexec/mysqld(+0x4c9b14)[0x55e61b3ccb14]
/usr/libexec/mysqld(+0x4c9926)[0x55e61b3cc926]
/usr/libexec/mysqld(+0xa81b05)[0x55e61b984b05]
/usr/libexec/mysqld(+0xa8312f)[0x55e61b98612f]
/usr/libexec/mysqld(+0xa83a90)[0x55e61b986a90]
/usr/libexec/mysqld(+0xa66ec2)[0x55e61b969ec2]
pthread_create.c:0(start_thread)[0x7f4c54ee6ea5]
2020-06-16 10:05:28 0 [Note] InnoDB: Buffer pool(s) load completed at 200616 10:05:28
/lib64/libc.so.6(clone+0x6d)[0x7f4c532988dd]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x0):
Connection ID (thread ID): 1
Status: NOT_KILLED
谷歌上找了一圈貌似可以設置數據庫為恢復模式：
添加個配置選項，因為用的是mariadb所以配置文件是my.cnf，如果是MySQL配置文件可能是mysql.cnf
[root@xc-jdsq ~(keystone_admin)]# vim /etc/my.cnf
#
# This group is read both both by the client and the server
# use it for options that affect everything
#
[client-server]
#
# This group is read by the server
#
[mysqld]
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
#
# include all files from the config directory
#
!includedir /etc/my.cnf.d
innodb_force_recovery = 2
這里innodb_force_recovery有6個等級
在使用之前一定要先看官方說明，此項恢復參數可能會丟失數據
試過innodb_force_recovery=1依然無法啟動mariadb，innodb_force_recovery=2才正常啟動。
啟動mariadb后查看mariadb服務狀態：
[root@xc-jdsq ~(keystone_admin)]# systemctl status mariadb
● mariadb.service - MariaDB 10.3 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
Active: active (running)since Tue 2020-06-16 14:32:53 CST; 28min ago
Docs: man:mysqld(8)
https://mariadb.com/kb/en/library/systemd/
Process: 12679 ExecStartPost=/usr/libexec/mysql-check-upgrade (code=exited, status=0/SUCCESS)
Process: 12609 ExecStartPre=/usr/libexec/mysql-prepare-db-dir %n (code=exited, status=0/SUCCESS)
Process: 12584 ExecStartPre=/usr/libexec/mysql-check-socket (code=exited, status=0/SUCCESS)
Main PID: 12648 (mysqld)
Status: "Taking your SQL requests now..."
Tasks: 328
Memory: 199.0M
CGroup: /system.slice/mariadb.service
└─12648 /usr/libexec/mysqld --basedir=/usr
Jun 16 14:32:53 xc-jdsq mysqld[12648]: 2020-06-16 14:32:53 0 [Warning] Could not increase number of max_open_files to more than 1024 (request: 8127)
Jun 16 14:32:53 xc-jdsq mysqld[12648]: 2020-06-16 14:32:53 0 [Warning] Changed limits: max_open_files: 1024 ?max_connections: 594 (was 4096) ?table_cache: 200 (was 2000)
Jun 16 14:32:53 xc-jdsq mysqld[12648]: 2020-06-16 14:32:53 0 [ERROR] WSREP: rsync SST method requires wsrep_cluster_address to be configured on startup.
Jun 16 14:32:53 xc-jdsq mysql-check-upgrade[12679]: The datadir located at /var/lib/mysql needs to be upgraded using 'mysql_upgrade' tool. This can be done using the following steps:
Jun 16 14:32:53 xc-jdsq mysql-check-upgrade[12679]: 1. Back-up your data before with 'mysql_upgrade'
Jun 16 14:32:53 xc-jdsq mysql-check-upgrade[12679]: 2. Start the database daemon using 'service mariadb start'
Jun 16 14:32:53 xc-jdsq mysql-check-upgrade[12679]: 3. Run 'mysql_upgrade' with a database user that has sufficient privileges
Jun 16 14:32:53 xc-jdsq mysql-check-upgrade[12679]: Read more about 'mysql_upgrade' usage at:
Jun 16 14:32:53 xc-jdsq mysql-check-upgrade[12679]: https://mariadb.com/kb/en/mariadb/documentation/sql-commands/table-commands/mysql_upgrade/
Jun 16 14:32:53 xc-jdsq systemd[1]: Started MariaDB 10.3 database server.
依然存在問題
但是openstack命令可以使用了
趁現在趕緊遷移實例。。。。。。。
------------------------------------------------------------------
嘗試解決第一個警告：
編輯服務配置文件：
[root@xc-jdsq ~(keystone_admin)]#?vim/usr/lib/systemd/system/mariadb.service
將LimitNOFILE=10000的注釋去除，谷歌搜來的解決方法，我也不知道這個干嘛的。
就是啟用LimitNOFILE選項。
然后重啟mariadb服務：
[root@xc-jdsq ~(keystone_admin)]# systemctl restart mariadb
Warning: mariadb.service changed on disk. Run 'systemctl daemon-reload' to reload units.
[root@xc-jdsq ~(keystone_admin)]#systemctl daemon-reload
[root@xc-jdsq ~(keystone_admin)]# systemctl status mariadb
● mariadb.service - MariaDB 10.3 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2020-06-16 15:07:27 CST; 20s ago
Docs: man:mysqld(8)
https://mariadb.com/kb/en/library/systemd/
Main PID: 34317 (mysqld)
Status: "Taking your SQL requests now..."
CGroup: /system.slice/mariadb.service
└─34317 /usr/libexec/mysqld --basedir=/usr
Jun 16 15:07:27 xc-jdsq mysqld[34317]: 2020-06-16 15:07:27 0 [Warning] Changed limits: max_open_files: 1024 ?max_connections: 594 (was 4096) ?table_cache: 200 (was 2000)
Jun 16 15:07:27 xc-jdsq mysqld[34317]: 2020-06-16 15:07:27 0 [ERROR] WSREP: rsync SST method requires wsrep_cluster_address to be configured on startup.
Jun 16 15:07:27 xc-jdsq mysql-check-upgrade[34356]: The datadir located at /var/lib/mysql needs to be upgraded using 'mysql_upgrade' tool. This can be done using the following steps:
Jun 16 15:07:27 xc-jdsq mysql-check-upgrade[34356]: 1. Back-up your data before with 'mysql_upgrade'
Jun 16 15:07:27 xc-jdsq mysql-check-upgrade[34356]: 2. Start the database daemon using 'service mariadb start'
Jun 16 15:07:27 xc-jdsq mysql-check-upgrade[34356]: 3. Run 'mysql_upgrade' with a database user that has sufficient privileges
Jun 16 15:07:27 xc-jdsq mysql-check-upgrade[34356]: Read more about 'mysql_upgrade' usage at:
Jun 16 15:07:27 xc-jdsq mysql-check-upgrade[34356]: https://mariadb.com/kb/en/mariadb/documentation/sql-commands/table-commands/mysql_upgrade/
Jun 16 15:07:27 xc-jdsq systemd[1]: Started MariaDB 10.3 database server.
Jun 16 15:07:38 xc-jdsq systemd[1]: [/usr/lib/systemd/system/mariadb.service:18] Assignment outside of section. Ignoring.
我也不知道LimitNOFILE選項干嘛的，第一個警告問題貌似解決了。
過了一會后那個警告又出現了。。。。。來自@騰訊云的拓荒者的文章顯示：
解決方法：
vi /etc/security/limits.conf
增加以下兩行
mysql hard nofile 65535
mysql soft nofile 65535
vi /usr/lib/systemd/system/mysqld.service(這里我的是mariadb.service)
增加下面一行
LimitNOFILE=65535
重啟服務器，問題解決。
問題并沒有解決。。。。。
之后我重新部署了openstack后發現這個問題本身就存在：
總結
以上是生活随笔為你收集整理的openstack 重启mysql_突然断电导致mariadb数据库无法启动（openstack 命令无法使用）...的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： random输出1到10之间_第43P，
- 下一篇： mysql把data移走后报错_【mys