openstack是通过rdoopenstack-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
-06-16 09:07:13.851 6460 ERROR nova.api.metadata.handler return self.dbapi.connect(*cargs, **cparams)
-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
-06-16 09:07:13.851 6460 ERROR nova.api.metadata.handler return Connection(*args, **kwargs)
-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__
-06-16 09:07:13.851 6460 ERROR nova.api.metadata.handler self.connect()
-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
-06-16 09:07:13.851 6460 ERROR nova.api.metadata.handler raise exc
-06-16 09:07:13.851 6460 ERROR nova.api.metadata.handler DBConnectionError: (pymysql.err.OperationalError) (, "Can't connect to MySQLserver on '192.168.1.99' ([Errno 111] ECONNREFUSED)") (Background on this error at: http://sqlalche.me/e/e3q8)
-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: /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: /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]: -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]: -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]: -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]: -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]: -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: /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 -06-16 09:29:48 CST; 4s ago
Docs: man:mysqld(8)
/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 /doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
-06-16 9:43:36 0 [Warning] You need to use --log-bin to make --binlog-format work.
-06-16 9:43:36 0 [Note] InnoDB: Using Linux native AIO
-06-16 9:43:36 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
-06-16 9:43:36 0 [Note] InnoDB: Uses event mutexes
-06-16 9:43:36 0 [Note] InnoDB: Compressed tables use zlib 1.2.7
-06-16 9:43:36 0 [Note] InnoDB: Number of pools: 1
-06-16 9:43:36 0 [Note] InnoDB: Using SSE2 crc32 instructions
-06-16 9:43:36 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
-06-16 9:43:37 0 [Note] InnoDB: Completed initialization of buffer pool
-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().
-06-16 9:43:37 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=2352300158
-06-16 9:43:37 0 [Note] InnoDB: Starting final batch to recover 4 pages from redo log.
-06-16 9:43:37 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
-06-16 9:43:37 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
-06-16 9:43:37 0 [Note] InnoDB: Creating shared tablespace for temporary tables
-06-16 9:43:37 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
-06-16 9:43:37 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
-06-16 9:43:37 0 [Note] InnoDB: Waiting for purge to start
-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 /
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: /kb/en/library/xtradbinnodb-recovery-modes/
InnoDB: about forcing recovery.
16 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 /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]
-06-16 9:43:37 0 [Note] InnoDB: 10.3.10 started; log sequence number 2352303796; transaction id 13955429
-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 /doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
-06-16 10:05:27 0 [Warning] You need to use --log-bin to make --binlog-format work.
-06-16 10:05:27 0 [Note] InnoDB: Using Linux native AIO
-06-16 10:05:27 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
-06-16 10:05:27 0 [Note] InnoDB: Uses event mutexes
-06-16 10:05:27 0 [Note] InnoDB: Compressed tables use zlib 1.2.7
-06-16 10:05:27 0 [Note] InnoDB: Number of pools: 1
-06-16 10:05:27 0 [Note] InnoDB: Using SSE2 crc32 instructions
-06-16 10:05:27 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
-06-16 10:05:27 0 [Note] InnoDB: Completed initialization of buffer pool
-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().
-06-16 10:05:27 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=2352300158
-06-16 10:05:27 0 [Note] InnoDB: Starting final batch to recover 4 pages from redo log.
-06-16 10:05:28 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
-06-16 10:05:28 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
-06-16 10:05:28 0 [Note] InnoDB: Creating shared tablespace for temporary tables
-06-16 10:05:28 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
-06-16 10:05:28 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
-06-16 10:05:28 0 [Note] InnoDB: 10.3.10 started; log sequence number 2352303796; transaction id 13955429
-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 /
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: /kb/en/library/xtradbinnodb-recovery-modes/
InnoDB: about forcing recovery.
16 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 /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...
-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]
-06-16 10:05:28 0 [Note] Plugin 'FEEDBACK' is disabled.
-06-16 10:05:28 0 [Note] Recovering after a crash using tc.log
-06-16 10:05:28 0 [Note] Starting crash recovery...
-06-16 10:05:28 0 [Note] Crash recovery finished.
sigaction.c:0(__restore_rt)[0x7f4c54eee630]
-06-16 10:05:28 0 [Warning] Failed to setup SSL
-06-16 10:05:28 0 [Warning] SSL error: SSL_CTX_set_default_verify_paths failed
-06-16 10:05:28 0 [Warning] SSL error: error:02001002:system library:fopen:No such file or directory
-06-16 10:05:28 0 [Warning] SSL error: error:D080:BIO routines:BIO_new_file:no such file
-06-16 10:05:28 0 [Warning] SSL error: error:0B084002:x509 certificate routines:X509_load_cert_crl_file:system lib
-06-16 10:05:28 0 [Note] Server socket created on IP: '0.0.0.0'.
:0(__GI_raise)[0x7f4c531d0387]
:0(__GI_abort)[0x7f4c531d1a78]
-06-16 10:05:28 0 [Note] Reading of all Master_info entries succeded
-06-16 10:05:28 0 [Note] Added new Master_info '' to hash table
-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]
-06-16 10:05:28 0 [Note] InnoDB: Buffer pool(s) load completed at 16 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所以配置文件是f,如果是MySQL配置文件可能是f
[root@xc-jdsq ~(keystone_admin)]# vim /etc/f
#
# 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/f.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 -06-16 14:32:53 CST; 28min ago
Docs: man:mysqld(8)
/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]: -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]: -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]: -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]: /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 -06-16 15:07:27 CST; 20s ago
Docs: man:mysqld(8)
/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]: -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]: -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]: /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后发现这个问题本身就存在: