I've a cluster consisting of 5 cassandra nodes. The cassandra version used is cassandra-3.11.3-1.noarch The keyspace strategy and is defined as follows: CREATE KEYSPACE my_keyspace WITH replication = {'class': 'NetworkTopologyStrategy', 'datacenter1': '2'} AND durable_writes = true; Now running queries on the cluster, the following issue occurs: > ReadFailure: Error from server: code=1300 [Replica(s) failed to execute read] > message="Operation failed - received 0 responses and 1 failures" > info={'consistency': 'LOCAL_ONE', 'received_responses': 0, 'required_responses': 1, 'failures': 1} > info={'failures': None, 'consistency': 'Not Set', 'required_responses': None, 'received_responses': None} Does anyone know what is causing this? If more information needed to better debug this problem, please let me know! **UPDATE 1** root# awk '!/#/' /etc/cassandra/conf/cassandra-rackdc.properties dc=datacenter1 rack=rack1

Can we install and run PL/SQL Developer on CentOS 7 server? I couldn't find installation documents anywhere. If the installation is possible can someone guide me on this.

I have mongo installed on Centos instance in AWS and I am connecting to the mongoDB server from my system. To connect from remote system we need to change bind_ip value to 0.0.0.0 in /etc/mongod.conf file and have done the same thing. Still I am not able to connect to the mongoDB from my system. When I checked weather the changed bind_ip is reflecting or not using netstat -a command the result is tcp 0 0 localhost:27017 0.0.0.0:* LISTEN but, to connect from remote system it should be tcp 0 0 0.0.0.0:27017 0.0.0.0:* LISTEN So the change in bind_ip value is not reflecting. Can anyone help on this?

After a server failure I'm not able to execute psql like psql -U postgres nor like sudo -u postgres psql. In both cases I'm asked for the user password despite I've modified the pg_hba.conf files to trust all local connections and I've tried virtually all proposed solutions along the web. Would it be possible to delete the postgres user and re-create it without loosing the data? That's assuming the issue might be that the user got corrupted during the system failure. ## Detailed info * Logs at /var/lib/pgsql/15/data/log are all empty. * Service status looks like: * /var/lib/pgsql/15/data/pg_hba.conflooks like -after some changes to try to login wihout password: * /var/lib/pgsql/data/pg_hba.conf looks like:

Im trying to install Oracle DB version 12.1.0.2.0-1 in my customer server, my installer file name is oracle-instantclient12.1-basic-12.1.0.2.0-1.x86_64.rpm. After run this file with sudo rpm -i oracle-instantclient12.1-basic-12.1.0.2.0-1.x86_64.rpm I can not see any message and ORACLE_BASE or ORACLE_HOME folder is missing too. I tried some steps: 1. export ORACLE_BASE=/usr/lib/oracle/12.1/client64 2. run oraenv, it asks ORACLE_SID and ORACLE_HOME but when enter I get error **ORACLE_BASE environment variable is not being set since this information is not available for the current user ID ABC. You can set ORACLE_BASE manually if it is required. Resetting ORACLE_BASE to its previous value or ORACLE_HOME The Oracle base has been set to /home/oracle** 3. Try to reinstall rpm file but nothing good happen. With missing home folder from installer I can not set many things, I can not do like desktop enviroment with user interface. Please help me.

Mysqld process showed all config file options on command line in CentOs 5 and CentOs 6. But it's not showing the same in CentOs 7. I am using mysql 5.7.21 on CentOs 7 example stated below and 5.7.19 on CentOs 6 example stated below. centos 6: mysql@xxxxxxxx ==> ps -ef | grep 3306 mysql 23084 1 0 Jan16 ? 00:00:00 /bin/sh /usr/bin/mysqld_safe --socket=/datadata/mysql.sock --port=3306 --max_allowed_packet=100M --datadir=/datadata --pid-file=/datadata/mysqld-qa.pid --max_connections=500 --open-files-limit=8192 --thread_cache_size=64 --delayed_insert_limit=4096 --query_cache_limit=1M --query_cache_size=32M --query_cache_type=1 --log_queries_not_using_indexes=off --log-error=/datalogs/mysql-error.log --expire_logs_days=3 --sort_buffer_size=2M --join_buffer_size=4M --read_buffer_size=2M --read_rnd_buffer_size=2M --tmp_table_size=64M --max_heap_table_size=64M --lower_case_table_names=0 --myisam_sort_buffer_size=16M --innodb_file_per_table --innodb_buffer_pool_size=1G --innodb_open_files=600 --innodb_max_dirty_pages_pct=10 --innodb_flush_log_at_trx_commit=0 --innodb_log_file_size=64M --innodb_log_buffer_size=4M --innodb_log_files_in_group=3 --innodb_flush_method=O_DIRECT --binlog_cache_size=64K --transaction_isolation=REPEATABLE-READ --server-id=3664 --log-bin=mysqldb01.bin --log-slave-updates --binlog_format=statement --sysdate-is-now=1 --sync-binlog=1 --sync-master-info=1 --log-queries-not-using-indexes=1 --innodb_buffer_pool_instances=5 --innodb_concurrency_tickets=1000000 --auto_increment_increment=10 --auto_increment_offset=2 --binlog_checksum=none --sql_mode=STRICT_ALL_TABLES --explicit_defaults_for_timestamp --open_files_limit=10000 --max_connections=4000 --table_open_cache=400 --binlog_format=statement --log_timestamps=SYSTEM --explicit_defaults_for_timestamp --master_info_repository=table --relay_log_info_repository=table --relay-log=dbtemp02-relay-bin --mysqld_safe_log_timestamps=SYSTEM --slave_net_timeout=3600 --default_password_lifetime=0 --relay_log_recovery=ON mysql 27230 23084 0 Jan16 ? 00:32:37 /usr/sbin/mysqld --basedir=/usr --datadir=/datadata --plugin-dir=/usr/lib64/mysql/plugin --max-allowed-packet=100M --max-connections=500 --thread-cache-size=64 --delayed-insert-limit=4096 --query-cache-limit=1M --query-cache-size=32M --query-cache-type=1 --log-queries-not-using-indexes=off --expire-logs-days=3 --sort-buffer-size=2M --join-buffer-size=4M --read-buffer-size=2M --read-rnd-buffer-size=2M --tmp-table-size=64M --max-heap-table-size=64M --lower-case-table-names=0 --myisam-sort-buffer-size=16M --innodb-file-per-table --innodb-buffer-pool-size=1G --innodb-open-files=600 --innodb-max-dirty-pages-pct=10 --innodb-flush-log-at-trx-commit=0 --innodb-log-file-size=64M --innodb-log-buffer-size=4M --innodb-log-files-in-group=3 --innodb-flush-method=O_DIRECT --binlog-cache-size=64K --transaction-isolation=REPEATABLE-READ --server-id=3664 --log-bin=mysqldb01.bin --log-slave-updates --binlog-format=statement --sysdate-is-now=1 --sync-binlog=1 --sync-master-info=1 --log-queries-not-using-indexes=1 --innodb-buffer-pool-instances=5 --innodb-concurrency-tickets=1000000 --auto-increment-increment=10 --auto-increment-offset=2 --binlog-checksum=none --sql-mode=STRICT_ALL_TABLES --explicit-defaults-for-timestamp --max-connections=4000 --table-open-cache=400 --binlog-format=statement --log-timestamps=SYSTEM --explicit-defaults-for-timestamp --master-info-repository=table --relay-log-info-repository=table --relay-log=dbtemp02-relay-bin --slave-net-timeout=3600 --default-password-lifetime=0 --relay-log-recovery=ON --log-error=/datalogs/mysql-error.log --open-files-limit=10000 --pid-file=/datadata/mysqld-qa.pid --socket=/datadata/mysql.sock --port=3306 centos 7: [mysql@xxxxxx binlogs]$ ps -ef | grep mysql mysql 16343 1 44 00:42 ? 00:53:00 /usr/sbin/mysqld --defaults-group-suffix=@0 --daemonize --pid-file=/var/run/mysqld/mysqld-0.pid Any idea how to display all variables in CentOs 7.

I upgraded mariadb on a Centos 7 box from 5.5 to 10.5 and after updating the tables, mariadb will no longer start. In /var/log/messages, I'm getting the following errors. Any help would be much appreciated!

Mar 23 10:22:20 theo systemd: Starting MariaDB 10.5.19 database server...
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Note] Starting MariaDB 10.5.19-MariaDB source revision f8a85af8ca1c937b8d4f847477bd282f80251cde as process 15269
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Note] InnoDB: Uses event mutexes
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Note] InnoDB: Compressed tables use zlib 1.2.7
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Note] InnoDB: Number of pools: 1
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Note] InnoDB: Using Linux native AIO
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Note] InnoDB: Completed initialization of buffer pool
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Note] InnoDB: 128 rollback segments are active.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: Operating system error number 13 in a file operation.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: Cannot open datafile for read-only: './mysql/gtid_slave_pos.ibd' OS error: 81
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: Operating system error number 13 in a file operation.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: Could not find a valid tablespace file for `mysql.gtid_slave_pos`. Please refer to https://mariadb.com/kb/en/innodb-data-dictionary-troubleshooting/  for how to resolve the issue.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Warning] InnoDB: Ignoring tablespace for mysql.gtid_slave_pos because it could not be opened.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: Operating system error number 13 in a file operation.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: Cannot open datafile for read-only: './mysql/innodb_index_stats.ibd' OS error: 81
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: Operating system error number 13 in a file operation.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: Could not find a valid tablespace file for `mysql.innodb_index_stats`. Please refer to https://mariadb.com/kb/en/innodb-data-dictionary-troubleshooting/  for how to resolve the issue.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Warning] InnoDB: Ignoring tablespace for mysql.innodb_index_stats because it could not be opened.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: Operating system error number 13 in a file operation.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: Cannot open datafile for read-only: './mysql/innodb_table_stats.ibd' OS error: 81
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: Operating system error number 13 in a file operation.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: Could not find a valid tablespace file for `mysql.innodb_table_stats`. Please refer to https://mariadb.com/kb/en/innodb-data-dictionary-troubleshooting/  for how to resolve the issue.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Warning] InnoDB: Ignoring tablespace for mysql.innodb_table_stats because it could not be opened.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: Operating system error number 13 in a file operation.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: Cannot open datafile for read-only: './mysql/transaction_registry.ibd' OS error: 81
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: Operating system error number 13 in a file operation.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] InnoDB: Could not find a valid tablespace file for `mysql.transaction_registry`. Please refer to https://mariadb.com/kb/en/innodb-data-dictionary-troubleshooting/  for how to resolve the issue.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Warning] InnoDB: Ignoring tablespace for mysql.transaction_registry because it could not be opened.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Note] InnoDB: Creating shared tablespace for temporary tables
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Note] InnoDB: 10.5.19 started; log sequence number 63339738232; transaction id 664540336
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Note] Plugin 'FEEDBACK' is disabled.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] Could not open mysql.plugin table: "Table 'mysql.plugin' doesn't exist". Some plugins may be not loaded
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Note] InnoDB: Buffer pool(s) load completed at 230323 10:22:20
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [Note] Server socket created on IP: '::'.
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.db' doesn't exist
Mar 23 10:22:20 theo mariadbd: 2023-03-23 10:22:20 0 [ERROR] Aborting
Mar 23 10:22:20 theo systemd: mariadb.service: main process exited, code=exited, status=1/FAILURE
Mar 23 10:22:20 theo systemd: Failed to start MariaDB 10.5.19 database server.
Mar 23 10:22:20 theo systemd: Unit mariadb.service entered failed state.
Mar 23 10:22:20 theo systemd: mariadb.service failed.

I have a CentOS 7 server with MySQL 5.7.4 installed. The machine has 8 cores and 16 GB of RAM, and only the MySQL service is running. The database is not very large, and there are not many queries. Normally, the server load is around 0.x. However, recently, I observed that every hour, the server load increases to about 10, and this lasts for about 10 minutes. The business department says that there are no scheduled tasks during this time, and during high load, the business system does not show any obvious problems. MySQL uses InnoDB, and the pool size is set to 10 GB. When the load is high, I logged in to MySQL with the root account and ran 'show processlist', but there were only a few queries, and the QPS was only about a dozen on average according to Prometheus. Other metrics did not show any significant differences. During this time, I used tools such as iostat/iotop to check for high I/O, but there were no significant differences compared to normal operation. Memory usage was also normal, with only 3-4 GB used out of 16 GB. The InnoDB pool hit rate and page free metrics were also normal. I enabled slow query logging with 'set global long_query_time=1', but there were no slow queries logged. The only abnormality I could observe was that the 'r' value reported by vmstat was around 10 during high load. Other metrics showed no significant differences compared to normal operation. please advise,thanks! normal state procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 5667436 5440 7967916 0 0 0 2 0 0 8 0 92 0 0 0 0 0 5667536 5440 7967916 0 0 0 0 3013 226 18 0 82 0 0 0 0 0 5667520 5440 7967916 0 0 0 0 2918 213 17 0 83 0 0 0 0 0 5667544 5440 7967916 0 0 0 0 3097 291 18 0 82 0 0 1 0 0 5667596 5440 7967916 0 0 0 0 3626 180 22 0 78 0 0 0 0 0 5667596 5440 7967916 0 0 0 0 3822 240 22 0 78 0 0 high load state procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 14 0 0 5666088 5440 7967860 0 0 0 2 0 0 8 0 92 0 0 12 0 0 5665908 5440 7967860 0 0 0 0 4612 340 24 0 76 0 0 10 0 0 5666032 5440 7967860 0 0 0 0 3055 318 17 0 83 0 0

I have a stored proc that's going through the tables, getting data, and write the result into a csv file (mainly to provide up to date data for FTP customers). When writing it to the local D: drive, everything runs fine. File writes as it should and everyone is happy. As I'm setting up new FTP server, I decided to try and ditch 12672 batch scripts transferring files from the DB server (Win Server 2012 r2 running SQL Server 2016) to the FPT server (CentOS 7 + Samba) and have the query outputs written straight there. SQL Server reports that query was executed successfully, but the output file disappears into a network black hole somewhere along the way. Slowly losing my mind with this one. Below list of things that I'm 99% sure are not causing the issue: - Samba - even though security is still mildly paranoid it's temporarily not user restricted. - Firewall - turning it off / on makes no difference whatsoever. - SELinux - same as firewalld, enforcing, permissive, disabled makes no difference. - File system permissions on Linux - 777'ed a test share, and su'ed as MSSQLUSER and successfully written a file in the same path I'm trying to get SQL server to write into, to check that. Samba logs absolutely nothing, which leads me to believe SQL isn't even trying to touch that share. There's nothing at all on the Linux side that would suggest SQL tried to make a connection. My current theory is that it's refusing to do it because it's not SQL Server's service account that mapped the share, so here goes: - Is there a way to map that network drive for all users? I'm reluctant adding extra code to the stored proc to map the drive / delete it afterwards. End game is to have all the internal transfers working this way, meaning quite a number of SP's to alter, and different schedules would at some point inevitably clash. Not to mention the insane number of mappings per day. Countless Google searches point towards a simple answer "No.", but as they say, hope dies last. - What potential consequences am I faced with if I were to change the service accounts (NT SERVICE\MSSQLSERVER) credentials? Unfortunately I haven't got a server I can sacrifice in the name of science and find out myself. - Is there a simple solution I'm missing that'd allow me to do this? Am I trying to re-invent the wheel? Any suggestions appreciated. I can do / change whatever I want on the Linux box, Windows side of things is a bit more complicated as my knowledge / experience with Microsoft systems is "mediocre" at best.

My Mongodb has disappeared 2 times, after 2 weeks, over the weekend within a 4 week time period. I had a snapshot to recover from but I can't keep on recovering my db every 2 weeks. In an ec2 instance where I hosted Mongo and the API in the same place, this is not an issue. Side note - does anyone know if it is possible to completely disable db.dropDatabase() or db.collection.drop()? Below is my mongod.conf file # where to write logging data. systemLog: destination: file logAppend: true path: /var/log/mongodb/mongod.log # Where and how to store data. storage: dbPath: /data logpath: /log/mongod.log journal: enabled: true # engine: # mmapv1: wiredTiger: prefixCompression: true # how the process runs processManagement: fork: true # fork and run in background pidFilePath: /var/run/mongodb/mongod.pid # location of pidfile timeZoneInfo: /usr/share/zoneinfo # network interfaces net: port: 27017 bindIp: 0.0.0.0 # bindIp: 127.0.0.1 # Listen to local interface only, comment to listen on all interfaces. Any ideas for how this happens or anyone who has ever solved a similar problem would be greatly appreciated. var/log/mongodb/mongodb.log 2018-02-26T17:14:09.799+0000 I CONTROL [main] ***** SERVER RESTARTED ***** 2018-02-26T17:14:09.987+0000 I CONTROL [initandlisten] MongoDB starting : pid=# port=port dbpath=/var/lib/mongo 64-bit host=ip-* 2018-02-26T17:14:09.987+0000 I CONTROL [initandlisten] db version v3.6.3 2018-02-26T17:14:09.987+0000 I CONTROL [initandlisten] git version: 9586e557d54ef70f9ca4b43c26892cd55257e1a5 2018-02-26T17:14:09.987+0000 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.0-fips 29 Mar 2010 2018-02-26T17:14:09.987+0000 I CONTROL [initandlisten] allocator: tcmalloc 2018-02-26T17:14:09.987+0000 I CONTROL [initandlisten] modules: none 2018-02-26T17:14:09.987+0000 I CONTROL [initandlisten] build environment: 2018-02-26T17:14:09.987+0000 I CONTROL [initandlisten] distmod: amazon 2018-02-26T17:14:09.987+0000 I CONTROL [initandlisten] distarch: x86_64 2018-02-26T17:14:09.987+0000 I CONTROL [initandlisten] target_arch: x86_64 2018-02-26T17:14:09.987+0000 I CONTROL [initandlisten] options: { config: "/etc/mongod.conf", net: { bindIp: "127.0.0.1", port: 27017 }, processManagement: { fork: true, pidFilePath: "/var/run/mongodb/mongod.pid", timeZoneInfo: "/usr/share/zoneinfo" }, storage: { dbPath: "/var/lib/mongo", journal: { enabled: true } }, systemLog: { destination: "file", logAppend: true, path: "/var/log/mongodb/mongod.log" } } 2018-02-26T17:14:09.988+0000 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=1382M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress), 2018-02-26T17:14:10.692+0000 I CONTROL [initandlisten] 2018-02-26T17:14:10.692+0000 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database. 2018-02-26T17:14:10.692+0000 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted. 2018-02-26T17:14:10.692+0000 I CONTROL [initandlisten] 2018-02-26T17:14:10.692+0000 I CONTROL [initandlisten] 2018-02-26T17:14:10.692+0000 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'. 2018-02-26T17:14:10.692+0000 I CONTROL [initandlisten] ** We suggest setting it to 'never' 2018-02-26T17:14:10.692+0000 I CONTROL [initandlisten] 2018-02-26T17:14:10.692+0000 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'. 2018-02-26T17:14:10.692+0000 I CONTROL [initandlisten] ** We suggest setting it to 'never' 2018-02-26T17:14:10.692+0000 I CONTROL [initandlisten] 2018-02-26T17:14:10.693+0000 I STORAGE [initandlisten] createCollection: admin.system.version with provided UUID: 038fb561-1163-46cb-bcae-b68ddebb4081 2018-02-26T17:14:10.700+0000 I COMMAND [initandlisten] setting featureCompatibilityVersion to 3.6 2018-02-26T17:14:10.703+0000 I STORAGE [initandlisten] createCollection: local.startup_log with generated UUID: c994079b-4e9b-416f-91b4-4cbc60e2c118 2018-02-26T17:14:10.710+0000 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/var/lib/mongo/diagnostic.data' 2018-02-26T17:14:10.710+0000 I NETWORK [initandlisten] waiting for connections on port 27017 2018-02-26T17:14:21.788+0000 I NETWORK [listener] connection accepted from 127.0.0.1:54282 #1 (1 connection now open) 2018-02-26T17:14:21.788+0000 I NETWORK [conn1] received client metadata from 127.0.0.1:54282 conn: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "3.6.3" }, os: { type: "Linux", name: "CentOS Linux release 7.4.1708 (Core) ", architecture: "x86_64", version: "Kernel 3.10.0-693.11.6.el7.x86_64" } } 2018-02-26T17:14:23.882+0000 I NETWORK [conn1] end connection 127.0.0.1:54282 (0 connections now open) 2018-02-26T17:19:10.711+0000 I STORAGE [thread2] createCollection: config.system.sessions with generated UUID: b181a7ff-d0e5-456e-bee5-ff7e40f32d0a 2018-02-26T17:19:10.739+0000 I INDEX [thread2] build index on: config.system.sessions properties: { v: 2, key: { lastUse: 1 }, name: "lsidTTLIndex", ns: "config.system.sessions", expireAfterSeconds: 1800 } 2018-02-26T17:19:10.739+0000 I INDEX [thread2] building index using bulk method; build may temporarily use up to 500 megabytes of RAM 2018-02-26T17:19:10.740+0000 I INDEX [thread2] build index done. scanned 0 total records. 0 secs 2018-02-26T17:28:02.551+0000 I NETWORK [listener] connection accepted from 127.0.0.1:54292 #2 (1 connection now open) 2018-02-26T17:28:02.551+0000 I NETWORK [conn2] received client metadata from 127.0.0.1:54292 conn: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Client", version: "3.6.3" }, os: { type: "Linux", name: "CentOS Linux release 7.4.1708 (Core) ", architecture: "x86_64", version: "Kernel 3.10.0-693.11.6.el7.x86_64" } } 2018-02-26T17:33:15.093+0000 I NETWORK [conn2] end connection 127.0.0.1:54292 (0 connections now open) 2018-02-26T17:34:20.689+0000 I CONTROL [signalProcessingThread] got signal 15 (Terminated), will terminate after current cmd ends 2018-02-26T17:34:20.689+0000 I NETWORK [signalProcessingThread] shutdown: going to close listening sockets... 2018-02-26T17:34:20.689+0000 I NETWORK [signalProcessingThread] removing socket file: /tmp/mongodb-27017.sock 2018-02-26T17:34:20.690+0000 I FTDC [signalProcessingThread] Shutting down full-time diagnostic data capture 2018-02-26T17:34:20.692+0000 I STORAGE [signalProcessingThread] WiredTigerKVEngine shutting down 2018-02-26T17:34:20.763+0000 I STORAGE [signalProcessingThread] shutdown: removing fs lock... 2018-02-26T17:34:20.763+0000 I CONTROL [signalProcessingThread] now exiting 2018-02-26T17:34:20.763+0000 I CONTROL [signalProcessingThread] shutting down with code:0 journalctl return these red lines Failed to create mount unit file /run/systemd/generator/data.mount, as it already exists. Duplicate entry in /etc/fstab? also for log.mount and journal.mount piix4_smbus 0000:00:01.3: SMBus base address uninitialized - upgrade BIOS or use force_addr=0xaddr Error: Driver 'pcspkr' is already registered, aborting...

I am installing mysql-workbench to migrate Postgres database to Mysql. > OS System Version: Red Hat Enterprise Linux Server release 7.2 (Maipo) I am installing mysql-workbench and follow these instructions. https://dev.mysql.com/doc/workbench/en/wb-installing-linux.html I have the following repo. repo id repo name status cloudera-manager Cloudera Manager, Version 5.7.5 7 mysql-connectors-community/x86_64 MySQL Connectors Community 30 mysql-tools-community/x86_64 MySQL Tools Community 40 mysql57-community/x86_64 MySQL 5.7 Community Server 164 rhui-REGION-client-config-server-7/x86_64 Red Hat Update Infrastructure 2.0 Client Configuration Server 7 6 rhui-REGION-rhel-server-releases/7Server/x86_64 Red Hat Enterprise Linux Server 7 (RPMs) 13,573 rhui-REGION-rhel-server-rh-common/7Server/x86_64 Red Hat Enterprise Linux Server 7 RH Common (RPMs) 209 repolist: 14,029 When I tried the command sudo yum -y install mysql-workbench-community I got the these erros. Error: Package: mysql-workbench-community-6.3.8-1.el7.x86_64 (mysql-tools-community) Requires: proj Error: Package: mysql-workbench-community-6.3.8-1.el7.x86_64 (mysql-tools-community) Requires: tinyxml Error: Package: mysql-workbench-community-6.3.8-1.el7.x86_64 (mysql-tools-community) Requires: python-paramiko >= 1.15.1 My question is how to find the repo of these dependencies package - proj, tinyxml, python-paramiko?

I'm running centos 7 with mySQL 5.7.xxx. mysql -V shows Ver 14.14 Distrib 5.7.26-29, but mysqld -V shows Ver 5.7.11-4. systemctl status mysql and systemctl status mysqld both show the same running database. SELECT @@version in the client shows 5.7.11-4-log. The database acts like it is running the previous version (some differences in JSON functions, for instance). Some background: when we started using JSON functions I attempted to update the database to the latest 5.7 version (on my way to updating to 8 preferably), but it didn't seem to work so I tabled it until I had more time. I'm not really sure what to do next. I don't know if this is a server problem or a database problem, or how to troubleshoot or proceed. Sorry I can't provide more information, but I'm not really sure what I'm looking for. I can backup the database and uninstall mysql completely if there's not a better way to go about it, just not sure what to do, and I also remember reading that you should update your database in place and not skip a major version on the way (ie, 5.5->5.6->5.7->8.0) but I don't know if that's true or not.

What's the best way to provide a MySql root password (~/.my.cnf) to cron job without root to have the home folder? the server I'm using is centos

I need a large database like 10TB-15TB in Postgresql for benchmarking. I've created a smaller ~100GB sample databases with pgbench like this:

pgbench -i -s 7000 --no-vacuum exampledb

However, I observe no speedup when doing parallel restore from custom format (created with pg_dump -F c ...). Including restoring from .sql dump as well:

time psql -d pgbench7000 < pgbench7000.sql

SET
SET
SET
SET
SET

set_config
------------
(1 row)

SET
SET
SET
SET
SET
SET

CREATE TABLE
ALTER TABLE

CREATE TABLE
ALTER TABLE

CREATE TABLE
ALTER TABLE

CREATE TABLE
ALTER TABLE

COPY 700000000
COPY 7000
COPY 0
COPY 70000

ALTER TABLE
ALTER TABLE
ALTER TABLE

real        32m1.539s
user        3m28.575s
sys         1m40.125s

####################

time pg_restore -d pgbench7000 pgbench7000.custom
real         20m7.504s
user         2m35.556s
sys          0m35.750s

####################

time pg_restore -j 16 -d pgbench7000 pgbench7000.custom

real         20m56.565s
user         2m57.547s
sys          0m40.096s

I've given Postgresql server generous resources:

max_connections = 1000              
shared_buffers = 94GB  # 25% of system's memory                
work_mem = 512MB                      
maintenance_work_mem = 12GB
effective_io_concurrency = 500
max_worker_processes = 50     
max_parallel_maintenance_workers = 10   
max_parallel_workers_per_gather = 10   
max_parallel_workers = 50

The box is really powerful, it has 374GB of RAM, 72 vCPUs and fast NAS storage mounted over NFS (that's where PG data directory resides). pgbench creates a rather simple database, there are like four tables and only one table is big and occupies most of space. Can this be the reason for lack of speedup? Can anybody tell where's the bottleneck? Or is it just db structure? Environment: Centos 7.9 (that's what I have to use), Postgres 11 installed from project repo.

MariaDB instance has been running well for ages, and suddenly, starting about 30 minutes ago, my apps get this error trying to connect: # mysql ERROR 2026 (HY000): Unknown SSL error My certs have been always under "/etc/my.cnf.d/certs/", generated by LetsEncrypt. They expire on 2021-11-04, last modified date 2021-08-06. my.cnf: ssl_cert = "/etc/my.cnf.d/certs/fullchain.pem" ssl_key = "/etc/my.cnf.d/certs/privkey.pem" Looking at the logs, there's nothing that hints anything. The latest log there is about "InnoDB: Online DDL", long ago. No recent yum system updates. **How can I investigate the cause of this problem?** From the research I made, the questions are due to setup issues, while in my case it's been working since always, but **"suddenly" failed, and I can't see what changed**. -- UPDATE: I wonder if this related, https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/ https://community.letsencrypt.org/t/help-thread-for-dst-root-ca-x3-expiration-september-2021/149190 > On September 30 2021, there will be a small change in how older browsers and devices trust Let’s Encrypt certificates. > (...) > DST Root CA X3 will expire on September 30, 2021. I wonder how can I make MariaDB trust ISRG Root X1!

A few days ago, our database server, (see specs below), spiked to 4800% CPU usage. The database is about 100GB. For 3 hours we tried to figure out what the issue was. We finally figured out a feature in our software was doing it, so we turned it off and rebooted the server and everything was fine. The next day we tried to turn the feature back on, but it started running at 4800% CPU usage. We tried to see if the usage would subside after we turned part of the feature off, but the usage didn’t drop. After 30 total minutes running, we ran the following commands. - systemctl reload mariadb.server -- Got error that it could not stop - systemctl resart mariadb.server -- Got error that it could not stop - systemctl restart mysql -- It tried to restart but then the database was corrupted. Here is a sample output from the sql logs. There are thousands of entries with similar statements: 2021-09-01 18:57:00 140014482597632 [ERROR] InnoDB: Page [page id: space=4, page number=119737] log sequence number 568999191060 is in the future! Current system log sequence number 568998232259. 2021-09-01 18:57:00 140014482597632 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.` After the restart, we couldn’t get the database back up again. We tried every recovery options available. We restored to a backup from the day before. The back up was done after the first 4800% CPU usage spike. We ran a health test against the database, and it came back 100% healthy. So, now the un-qualified consensus is that it was the restart that crashed the database. Here are the server specifications - AWS EC2 Instance c5.12xlarge - 48 vCPU - 69 GB RAM - 12 Gbps Network Bandwidth - 9.5K Mbps EBS Bandwidth - Maria DB 10.2.39 - Centos 7 Any thoughts on whether or not the service restart could have caused this catastrophic failure? I know this is a wide-open question, but I have been looking through may articles and nothing that states a service restart would do this. However, we need to rule things out, so any input would be helpful.

I am running postgresql-9.6 on Rhel7. I know that the default/root user doesnt have a password, however i will like to use phpPgAdmin to do my work. the problem is I have edited my pg_hba.conf file to look as follow, (based on various documentation I have read so far:

local   all             all                          password
# IPv4 local connections:
host    all             all       127.0.0.1/32       password
# IPv6 local connections:
host    all             all             ::1/128      ident

The only problem is that after this configuration even the default user postgres has lost access completely. When I try to log in as the root user with psql and and enter my computer's root user's password this is what what happens:

-bash-4.2$ psql
Password:
psql: FATAL:  password authentication failed for user "postgres"

but when I change the above configuration on the pg_hba.conf file to:

peer
ident
ident

I can log in as root however phpPgAdmin won't let me in without a password.

I need use JSON_OBJECT builtin mariadb function, but mariadb version in server 10.0.xx, then we upgrade to 10.4.20-MariaDB. Then now mariadb version is 10.4.20-MariaDB But some table can't be accessed with error message:

select * from ;
ERROR 1932 (42S02): Table '' doesn't exist in engine

I was browse then found that should run mysql_upgrade again has some error:

mysql.gtid_slave_pos
Error    : Table 'mysql.gtid_slave_pos' doesn't exist in engine
status   : Operation failed

mysql.innodb_index_stats
Error    : Table 'mysql.innodb_index_stats' doesn't exist in engine
status   : Operation failed

mysql.innodb_table_stats
Error    : Table 'mysql.innodb_table_stats' doesn't exist in engine
status   : Operation failed

Environment: -OS: CentOS Linux release 7.9.2009 (Core)

We are facing problem of high cpu usage for mysql process (almost 100%). Here is the information related to server Server Infos: VPS - CENTOS 7.9 kvm - 6 GB RAM - 4 Core CPU - 180 GB SSD - MariaDB And recently cpu usage was really high, # uptime 13:49:37 19 days, 0 users, load average: 33.69, 35.28, 36.05 o i noticed mysqld is taking much more CPU PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ 14861 mysql 20 0 9.8g 476704 2028 S 196.0 8.0 237:44.81 running mysql # mysql Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 22885 Server version: 10.3.29-MariaDB MariaDB Server status shows mysql Ver 15.1 Distrib 10.3.29-MariaDB, for Linux (x86_64) using readline5.1 Connection id: 22885 Current database: Current user: root@localhost SSL: Not in use Current pager: stdout Using outfile: '' Using delimiter: ; Server: MariaDB Server version: 10.3.29-MariaDB MariaDB Server Protocol version: 10 Connection: Localhost via UNIX socket Server characterset: utf8 Db characterset: utf8 Client characterset: utf8 Conn. characterset: utf8 UNIX socket: /var/lib/mysql/mysql.sock Uptime: 2 hours 30 min 7 sec Threads: 82 Questions: 3797854 Slow queries: 9763 Opens: 871 Flush tables: 1 Open tables: 864 Queries per second avg: 421.655 my /etc/my.cnf # cat /etc/my.cnf [mysqld] log-error=/var/lib/mysql/vps-5972435.hdfilmes.xyz.err performance-schema=0 default-storage-engine=MyISAM max_allowed_packet=268435456 table_definition_cache=612 key_buffer_size=1G query_cache_min_res_unit=2000 query_cache_size=0 query_cache_type=0 query_cache_limit=1048576 join_buffer_size=1M tmp_table_size=64M max_heap_table_size=64M performance_schema = ON innodb_file_per_table=1 innodb_buffer_pool_size=4600M innodb_log_buffer_size=212M innodb_buffer_pool_instances=5 innodb_flush_log_at_trx_commit = 1 innodb_flush_method = O_DIRECT innodb_log_file_size=642M sort_buffer_size=2M read_buffer_size=1M read_rnd_buffer_size=1M sql_mode=NO_ENGINE_SUBSTITUTION character-set-server=utf8 collation-server=utf8_general_ci open_files_limit=40000 table_open_cache=2200 wait_timeout=28800 interactive_timeout=28800 max_connections=1000 How can i find out why is mysqld is using so much CPU ? and how can i fix it ? SHOW VARIABLES LIKE '%buffer%'; MariaDB [(none)]> SHOW VARIABLES LIKE '%buffer%'; +-------------------------------------+----------------+ | Variable_name | Value | +-------------------------------------+----------------+ | aria_pagecache_buffer_size | 134217728 | | aria_sort_buffer_size | 268434432 | | bulk_insert_buffer_size | 8388608 | | innodb_buffer_pool_chunk_size | 134217728 | | innodb_buffer_pool_dump_at_shutdown | ON | | innodb_buffer_pool_dump_now | OFF | | innodb_buffer_pool_dump_pct | 25 | | innodb_buffer_pool_filename | ib_buffer_pool | | innodb_buffer_pool_instances | 5 | | innodb_buffer_pool_load_abort | OFF | | innodb_buffer_pool_load_at_startup | ON | | innodb_buffer_pool_load_now | OFF | | innodb_buffer_pool_size | 5368709120 | | innodb_change_buffer_max_size | 25 | | innodb_change_buffering | all | | innodb_log_buffer_size | 222298112 | | innodb_sort_buffer_size | 1048576 | | join_buffer_size | 1048576 | | join_buffer_space_limit | 2097152 | | key_buffer_size | 1073741824 | | mrr_buffer_size | 262144 | | myisam_sort_buffer_size | 134216704 | | net_buffer_length | 16384 | | preload_buffer_size | 32768 | | read_buffer_size | 1048576 | | read_rnd_buffer_size | 1048576 | | sort_buffer_size | 2097152 | | sql_buffer_result | OFF | +-------------------------------------+----------------+ 28 rows in set (0.024 sec) SHOW VARIABLES LIKE 'query%'; MariaDB [(none)]> SHOW VARIABLES LIKE 'query%'; +------------------------------+---------+ | Variable_name | Value | +------------------------------+---------+ | query_alloc_block_size | 16384 | | query_cache_limit | 1048576 | | query_cache_min_res_unit | 2000 | | query_cache_size | 0 | | query_cache_strip_comments | OFF | | query_cache_type | OFF | | query_cache_wlock_invalidate | OFF | | query_prealloc_size | 24576 | +------------------------------+---------+ 8 rows in set (0.002 sec) i ran mysqltuner.pl # ./mysqltuner.pl >> MySQLTuner 1.7.21 - Major Hayden >> Bug reports, feature requests, and downloads at http://mysqltuner.pl/ >> Run with '--help' for additional options and output filtering [--] Skipped version check for MySQLTuner script [OK] Currently running supported MySQL version 10.3.29-MariaDB [OK] Operating on 64-bit architecture -------- Log file Recommendations ------------------------------------------------------------------ [OK] Log file /var/lib/mysql/vps-5972435.hdfilmes.xyz.err exists [--] Log file: /var/lib/mysql/vps-5972435.hdfilmes.xyz.err(840M) [OK] Log file /var/lib/mysql/vps-5972435.hdfilmes.xyz.err is not empty [!!] Log file /var/lib/mysql/vps-5972435.hdfilmes.xyz.err is bigger than 32 Mb [OK] Log file /var/lib/mysql/vps-5972435.hdfilmes.xyz.err is readable. [!!] /var/lib/mysql/vps-5972435.hdfilmes.xyz.err contains 137 warning(s). [!!] /var/lib/mysql/vps-5972435.hdfilmes.xyz.err contains 15930 error(s). [--] 30 start(s) detected in /var/lib/mysql/vps-5972435.hdfilmes.xyz.err [--] 1) 2021-06-15 11:32:30 0 [Note] /usr/sbin/mysqld: ready for connections. [--] 2) 2021-06-15 10:27:44 0 [Note] /usr/sbin/mysqld: ready for connections. [--] 3) 2021-06-14 21:51:45 0 [Note] /usr/sbin/mysqld: ready for connections. [--] 4) 2021-06-13 23:22:14 0 [Note] /usr/sbin/mysqld: ready for connections. [--] 5) 2021-06-13 22:59:25 0 [Note] /usr/sbin/mysqld: ready for connections. [--] 6) 2021-06-13 22:38:14 0 [Note] /usr/sbin/mysqld: ready for connections. [--] 7) 2021-06-13 22:32:08 0 [Note] /usr/sbin/mysqld: ready for connections. [--] 8) 2021-06-13 22:30:32 0 [Note] /usr/sbin/mysqld: ready for connections. [--] 9) 2021-06-13 22:19:49 0 [Note] /usr/sbin/mysqld: ready for connections. [--] 10) 2021-06-13 22:19:20 0 [Note] /usr/sbin/mysqld: ready for connections. [--] 18 shutdown(s) detected in /var/lib/mysql/vps-5972435.hdfilmes.xyz.err [--] 1) 2021-06-15 11:32:27 0 [Note] /usr/sbin/mysqld: Shutdown complete [--] 2) 2021-06-15 10:27:40 0 [Note] /usr/sbin/mysqld: Shutdown complete [--] 3) 2021-06-14 21:50:59 0 [Note] /usr/sbin/mysqld: Shutdown complete [--] 4) 2021-06-13 23:21:27 0 [Note] /usr/sbin/mysqld: Shutdown complete [--] 5) 2021-06-13 22:37:33 0 [Note] /usr/sbin/mysqld: Shutdown complete [--] 6) 2021-06-13 22:32:05 0 [Note] /usr/sbin/mysqld: Shutdown complete [--] 7) 2021-06-13 22:30:21 0 [Note] /usr/sbin/mysqld: Shutdown complete [--] 8) 2021-06-13 22:11:29 0 [Note] /usr/sbin/mysqld: Shutdown complete [--] 9) 2021-06-13 22:01:52 0 [Note] /usr/sbin/mysqld: Shutdown complete [--] 10) 2021-06-13 21:56:42 0 [Note] /usr/sbin/mysqld: Shutdown complete -------- Storage Engine Statistics ----------------------------------------------------------------- [--] Status: +Aria +CSV +InnoDB +MEMORY +MRG_MyISAM +MyISAM +PERFORMANCE_SCHEMA +SEQUENCE [--] Data in MyISAM tables: 244.2M (Tables: 82) [--] Data in InnoDB tables: 642.9M (Tables: 59) [OK] Total fragmented tables: 0 -------- Analysis Performance Metrics -------------------------------------------------------------- [--] innodb_stats_on_metadata: OFF [OK] No stat updates during querying INFORMATION_SCHEMA. -------- Security Recommendations ------------------------------------------------------------------ [OK] There are no anonymous accounts for any database users [OK] All database users have passwords assigned [!!] There is no basic password file list! -------- CVE Security Recommendations -------------------------------------------------------------- [--] Skipped due to --cvefile option undefined -------- Performance Metrics ----------------------------------------------------------------------- [--] Up for: 2h 41m 46s (4M q [422.906 qps], 24K conn, TX: 11G, RX: 530M) [--] Reads / Writes: 99% / 1% [--] Binary logging is disabled [--] Physical Memory : 5.7G [--] Max MySQL memory : 262.2G [--] Other process memory: 0B [--] Total buffers: 6.4G global + 261.3M per thread (1000 max threads) [--] P_S Max memory usage: 622M [--] Galera GCache Max memory usage: 0B [!!] Maximum reached memory usage: 26.6G (470.10% of installed RAM) [!!] Maximum possible memory usage: 262.2G (4624.61% of installed RAM) [!!] Overall possible memory usage with other process exceeded memory [OK] Slow queries: 0% (10K/4M) [OK] Highest usage of available connections: 7% (77/1000) [OK] Aborted connections: 0.02% (5/24969) [!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance [OK] Query cache is disabled by default due to mutex contention on multiprocessor machines. [OK] Sorts requiring temporary tables: 0% (0 temp sorts / 952K sorts) [OK] No joins without indexes [!!] Temporary tables created on disk: 90% (875K on disk / 968K total) [OK] Thread cache hit rate: 99% (77 created / 24K connections) [OK] Table cache hit rate: 99% (874 open / 881 opened) [OK] table_definition_cache(612) is upper than number of tables(406) [OK] Open file limit used: 0% (324/40K) [OK] Table locks acquired immediately: 99% (82K immediate / 82K locks) -------- Performance schema ------------------------------------------------------------------------ [--] Memory used by P_S: 622.1M [--] Sys schema is installed. -------- ThreadPool Metrics ------------------------------------------------------------------------ [--] ThreadPool stat is enabled. [--] Thread Pool Size: 4 thread(s). [--] Using default value is good enough for your version (10.3.29-MariaDB) -------- MyISAM Metrics ---------------------------------------------------------------------------- [!!] Key buffer used: 18.6% (199M used / 1B cache) [OK] Key buffer size / total MyISAM indexes: 1.0G/66.8M [OK] Read Key buffer hit rate: 99.9% (4M cached / 3K reads) [OK] Write Key buffer hit rate: 100.0% (46 cached / 46 writes) -------- InnoDB Metrics ---------------------------------------------------------------------------- [--] InnoDB is enabled. [--] InnoDB Thread Concurrency: 0 [OK] InnoDB File per table is activated [OK] InnoDB buffer pool / data size: 5.0G/642.9M [OK] Ratio InnoDB log file size / InnoDB Buffer pool size: 642.0M * 2/5.0Gshould be equal to 25% [OK] InnoDB buffer pool instances: 5 [--] Number of InnoDB Buffer Pool Chunk : 40 for 5 Buffer Pool Instance(s) [OK] Innodb_buffer_pool_size aligned with Innodb_buffer_pool_chunk_size & Innodb_buffer_pool_instances [OK] InnoDB Read buffer efficiency: 100.00% (13859785816 hits/ 13859814226total) [!!] InnoDB Write Log efficiency: 47.62% (15697 hits/ 32965 total) [OK] InnoDB log waits: 0.00% (0 waits / 17268 writes) -------- Aria Metrics ------------------------------------------------------------------------------ [--] Aria Storage Engine is enabled. [OK] Aria pagecache size / total Aria indexes: 128.0M/0B [!!] Aria pagecache hit rate: 92.7% (12M cached / 875K reads) -------- TokuDB Metrics ---------------------------------------------------------------------------- [--] TokuDB is disabled. -------- XtraDB Metrics ---------------------------------------------------------------------------- [--] XtraDB is disabled. -------- Galera Metrics ---------------------------------------------------------------------------- [--] Galera is disabled. -------- Replication Metrics ----------------------------------------------------------------------- [--] Galera Synchronous replication: NO [--] No replication slave(s) for this server. [--] Binlog format: MIXED [--] XA support enabled: ON [--] Semi synchronous replication Master: OFF [--] Semi synchronous replication Slave: OFF [--] This is a standalone server -------- Recommendations --------------------------------------------------------------------------- General recommendations: /var/lib/mysql/vps-5972435.hdfilmes.xyz.err is > 32Mb, you should analyze why or implement a rotation log strategy such as logrotate! Control warning line(s) into /var/lib/mysql/vps-5972435.hdfilmes.xyz.err file Control error line(s) into /var/lib/mysql/vps-5972435.hdfilmes.xyz.errfile MySQL was started within the last 24 hours - recommendations may be inaccurate Reduce your overall MySQL memory footprint for system stability Dedicate this server to your database for highest performance. Configure your accounts with ip or subnets only, then update your configuration with skip-name-resolve=1 When making adjustments, make tmp_table_size/max_heap_table_size equal Reduce your SELECT DISTINCT queries which have no LIMIT clause Variables to adjust: *** MySQL's maximum memory usage is dangerously high *** *** Add RAM before increasing MySQL buffer variables *** tmp_table_size (> 64M) max_heap_table_size (> 64M) Additional details. # free -h total used free shared buff/cache available Mem: 5.7G 5.4G 134M 8.7M 180M 94M Swap: 4.0G 3.2G 816M top for most active apps PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ 14861 mysql 20 0 9.8g 493096 1892 S 162.9 8.3 287:12.22 32657 pitaraf+ 20 0 517220 51044 4196 R 15.2 0.9 1:00.54 32642 pitaraf+ 20 0 490076 24728 4184 R 12.3 0.4 1:09.38 31514 pitaraf+ 20 0 519328 52932 4076 R 11.9 0.9 1:40.88 32656 pitaraf+ 20 0 487976 25284 4068 R 11.9 0.4 0:55.19 32623 pitaraf+ 20 0 517168 54448 4712 R 11.3 0.9 1:21.76 441 pitaraf+ 20 0 506356 42752 4172 R 10.9 0.7 0:54.74 444 pitaraf+ 20 0 506408 42188 4060 R 10.9 0.7 0:48.77 520 pitaraf+ 20 0 504452 38544 4084 R 10.9 0.6 1:10.51 32750 pitaraf+ 20 0 506464 42336 4128 R 10.9 0.7 1:01.96 524 pitaraf+ 20 0 490072 25860 4728 R 10.6 0.4 0:56.50 32724 pitaraf+ 20 0 479908 14852 4024 R 10.6 0.2 1:02.63 3519 pitaraf+ 20 0 516988 53432 4164 R 10.3 0.9 0:07.88 30953 pitaraf+ 20 0 525536 58888 4012 R 10.3 1.0 2:05.08 32618 pitaraf+ 20 0 513192 48092 4096 R 9.9 0.8 1:05.61 32749 pitaraf+ 20 0 529428 63972 4720 R 9.6 1.1 0:43.49 447 pitaraf+ 20 0 492160 27064 4060 R 8.9 0.5 0:59.22 ulimit -a # ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) unlimited file size (blocks, -f) unlimited pending signals (-i) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1048576 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) unlimited real-time priority (-r) unlimited stack size (kbytes, -s) unlimited cpu time (seconds, -t) unlimited max user processes (-u) unlimited virtual memory (kbytes, -v) unlimited file locks (-x) unlimited df -h # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 2.9G 0 2.9G 0% /dev tmpfs 2.9G 0 2.9G 0% /dev/shm tmpfs 2.9G 113M 2.8G 4% /run tmpfs 2.9G 0 2.9G 0% /sys/fs/cgroup /dev/sda1 178G 98G 72G 58% / /dev/loop0 3.9G 16M 3.6G 1% /tmp SHOW FULL PROCESSLIST - [TXT (PasteBin)](https://pastebin.com/raw/KFevUEWu)

I have an issue to add instance to MySQL InnoDB Cluster using MySQL Shell. Here are the steps that I have done: 1. Login to one DB-01 node 2. Run command: mysqlsh 3. shell.connect('username@ip-address:port'); 4. cluster = dba.createCluster('cluster-name'); 5. Checking the cluster status: cluster.status(). Here is everything ok. I have one instance in the cluster. 6. cluster.addInstance('username@ip-address-of-db-02-node:port'); 7. Getting an error. MySQL log from DB-02 node contains the following errors: > [Repl] Plugin group_replication reported: '[GCS] Error connecting to all peers. Member join failed. Local port: 33061' 2020-12-26T14:40:29.234106Z 0 [ERROR] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] The member was unable to join the group. Local port: 33061' It's same when I try to add DB-03 node into cluster. All servers are in the same VLAN and have been configured using mysql shell (there is same user and pass for all nodes). IP tables service is not enabled and SELinux is disabled. When I tried telnet from DB-02 to DB-01 on port 33061, it's opened but when I run telnet from DB-01 to DB-02 then connection is refused. Does anyone have an idea how to fix this issue?