當前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

openstack 重启mysql_突然断电导致mariadb数据库无法启动（openstack 命令无法使用）...

發布時間：2024/10/8 数据库 27 豆豆

生活随笔收集整理的這篇文章主要介紹了 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]

我菜鳥一個也看不懂數據庫

之后貌似錯誤又變了：

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