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后发现这个问题本身就存在：