I have a PXC with three nodes. But when one of the node crashed, the other nodes followed suit.
What does the first paragraph (Trying to get some variables...) of the error below mean? In what circumstance does this error or message happen?
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f7bf80f5c30): is an invalid pointer
Connection ID (thread ID): 323203618
Status: NOT_KILLED
You may download the Percona XtraDB Cluster operations manual by visiting
http://www.percona.com/software/percona-xtradb-cluster/. You may find information
in the manual which will help you identify the cause of the crash.
150809 05:13:51 mysqld_safe Number of processes running now: 0
150809 05:13:51 mysqld_safe WSREP: not restarting wsrep node automatically
150809 05:13:51 mysqld_safe mysqld from pid file /var/lib/mysql/db-3-2.pid ended
Related
My EC2 instance ran out of space so followed directions to backup and restore to a larger volume. After I did that, I couldn't start up MySQL anymore.
When I try to start MySQL on my EC2 instance with Bitnami, it just hangs there. It looks like it's because I don't have a socket file at all where it should be /opt/bitnami/mysql/tmp/mysql.sock. Instead I just have a lock file there (/opt/bitnami/mysql/tmp/mysql.sock.lock).
One source I found said to recreate a symlink to another .sock file but I think because it's Bitnami it's in a different location and I'm not sure where that is.
Of course, it's possible that this sock file is just a red herring so I'm also digging into other possible causes. Has anyone else had this happen before? It seems like a problem that could be common but I haven't been able to find much about this aside from the vanilla Bitnami docs.
If you look at the MySQL script that Bitnami has (found at /opt/bitnami/mysql/scripts/ctl.sh) you can see that the MySQL log file is located at /opt/bitnami/mysql/data/mysqld.log on Bitnami instances. Look at the most recent logs, mine showed the following toward the end of the logs:
[Warning] Failed to set up SSL because of the following SSL library error: SSL context is not usable without certificate and private key
[Note] Server hostname (bind-address): 'x.x.x.x'; port: xxxx
[Note] - 'xxx.x.x.x' resolves to 'xxx.x.x.x';
[Note] Server socket created on IP: 'xxx.x.x.x'.
[ERROR] Unix socket lock file is empty /opt/bitnami/mysql/tmp/mysql.sock.lock.
[ERROR] Unable to setup unix socket lock file.
[ERROR] Aborting
Originally I thought the SSL thing was the issue but someone else pointed out that this is just a warning.
Ultimately I was able to fix this by just backing up the lock file (just in case) and then removing it:
# Back that thang up
sudo cp /opt/bitnami/mysql/tmp/mysql.sock.lock /opt/bitnami/mysql/tmp/mysql.sock.lock.backup
# Remove it
sudo rm /opt/bitnami/mysql/tmp/mysql.sock.lock
# Fire it up again
sudo /opt/bitnami/ctlscript.sh start mysql
I use MySQL-8.0.12 to setup a master-slave replication cluster. But slave always gets following errors, does anyone know how to fix this ?
2018-11-01T04:17:58.327576Z 19 [ERROR] [MY-010834] [Server] next log
error: -1 offset: 50 log: ./mysql-relay-bin.000002 included: 1,
2018-11-01T04:17:58.327675Z 19 [ERROR] [MY-010596] [Repl] Error
reading relay log event for channel '': Error purging processed logs,
2018-11-01T04:17:58.327932Z 19 [ERROR] [MY-013121] [Repl] Slave SQL
for channel '': Relay log read failure: Could not parse relay log
event entry. The possible reasons are: the master's binary log is
corrupted (you can check this by running 'mysqlbinlog' on the binary
log), the slave's relay log is corrupted (you can check this by
running 'mysqlbinlog' on the relay log), a network problem, or a bug
in the master's or slave's MySQL code. If you want to check the
master's binary log or slave's relay log, you will be able to know
their names by issuing 'SHOW SLAVE STATUS' on this slave. Error_code:
MY-013121,
2018-11-01T04:17:58.327982Z 19 [ERROR] [MY-010586] [Repl] Error
running query, slave SQL thread aborted. Fix the problem, and restart
the slave SQL thread with "SLAVE START". We stopped at log
'mysql-bin.000003' position 805
check disk space in slave
faced the same issue once.
during the replication, if slave server disk is full and no space left mysql replication thread wait for the disk to be freed wait time is 60 sec if the server restarted during that time then relay log cannot be recovered and slave cannot read the relay log.
I am trying to setup MySql 5.7 on CentOS 6.10. I've installed MySQL but when I try to run sudo service mysqld start, it is not starting. The error is
2018-11-05T17:14:57.569757Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2018-11-05T17:14:57.573328Z 0 [Note] mysqld (mysqld 5.7.24) starting as process 10355 ...
2018-11-05T17:14:57.575610Z 0 [ERROR] Fatal error: Please read "Security" section of the manual to find out how to run mysqld as root!
2018-11-05T17:14:57.575652Z 0 [ERROR] Aborting
2018-11-05T17:14:57.575671Z 0 [Note] Binlog end
2018-11-05T17:14:57.575741Z 0 [Note] mysqld: Shutdown complete
I guess it is something to do with selecting the user type as root but I'm not able to figure out what to do. Can someone help?Thanks in advance
It looks like mysqld is configured to run as the root user right now, which is not a recommended way for it to run--hence the hard warnings forcing you to change your configuration. You should instead run as the mysql user that was created for you when you installed the package.
You can see the user mysqld is set up to run under by looking in the [mysqld] section of my.cnf. It seems most likely you have user=root, or the command line flag of --user=root is being applied.
Best practice would be to configure it to use the non-privileged mysql user instead.
Relevant documentation:
The How to Run MySQL as a Normal User documentation page indicates that:
the MySQL server mysqld should be started by the local mysql operating system user. Starting by another operating system user is not supported by the init scripts that are included as part of the installation.
MariaDB (a fork of MySQL) provides a documentation page called Running mysqld as root which indicates:
MariaDB should never normally be run as the system's root user (this is unrelated to the MariaDB root user). If it is, any user with the FILE privilege can create or modify any files on the server as root.
MariaDB will normally return the error Fatal error: Please read "Security" section of the manual to find out how to run mysqld as root! if you attempt to run mysqld as root. If you need to override this restriction for some reason, start mysqld with the user=root option.
Better practice, and the default in most situations, is to use a separate user, exclusively used for MariaDB. In most distributions, this user is called mysql.
My /var is full (98% full) so I do try to move the mysql data to /data
I followed instructions from : How to change MySQL data directory?
Problem is : I cannot stop mysql
/etc/init.d/mysql stop
gives:
[ ok ] Stopping mysql (via systemctl): mysql.service.
Byt mysql keeps running.
I tried with
/etc/init.d/mysql stop
STill cannot stop it
# ps -A |grep mysql
12683 ? 00:00:00 mysqld_safe
13028 ? 5-19:29:43 mysqld
Any idea ?
Did you run the init.d script as root? You can't start or stop services unless you run the command as a superuser.
You can also try shutting down the mysql service using this mysql tool:
mysqladmin -uroot -p shutdown
Read more here: https://dev.mysql.com/doc/refman/8.0/en/mysqladmin.html
If that doesn't work, I'd check the MySQL error log (the location of the error log varies, but it may be in your datadir or else in /var/log somewhere).
Perhaps it's just taking a long time to do a clean shutdown. MySQL clean shutdown requires it write all the dirty pages in the buffer pool to the disk, in the correct place in the tablespace. This can take a long time if you have a large buffer pool and a lot of modified pages. If it takes too long, the init.d script may give up waiting. But the shutdown is still progressing. The error log may tell you what it's doing.
If the shutdown command doesn't help, the last resort is to terminate the processes with prejudice (sudo kill -9 12683 13028). If you use a durable storage engine like InnoDB (and haven't disabled durability), this won't corrupt your data, but it doesn't really save you any time, because it'll have to perform crash recovery the next time you start the service.
I would like to ask a help for the problem I encountered. My mysql server suddenly stopped after I install php-soap. I don't know why it get stopped actually...
Since it's stopped I tried to start it by typing the line:
# /etc/init.d/mysqld start
After this, I get this message:
MySQL Daemon failed to start.
Starting mysqld: [FAILED]
Starting mysql seems failed. Since I tried it numerous times and got this result a numerous time. I checked the mysqlog and here's what I got.
==== MYSQL LOG ====
120511 21:34:43 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
120511 21:34:43 [ERROR] Error message file '/usr/share/mysql/english/errmsg.sys' had only 481 error messages,
but it should contain at least 641 error messages.
Check that the above file is the right version for this program!
/usr/libexec/mysqld: Unknown error 1146
120511 21:34:43 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
120511 21:34:43 InnoDB: Initializing buffer pool, size = 8.0M
120511 21:34:44 InnoDB: Completed initialization of buffer pool
120511 21:34:44 InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'open'.
InnoDB: Cannot continue operation.
120511 21:34:44 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
Other infos:
OS: CentOS 5.5 64bit
Mysql Version: Sorry I couldn't get the version of mysql installed on my server due this error I am getting:
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)
Can somebody help me to resolve this problem?
Thank you in advanced.
looks like your installation of mysql is not corrupt with /usr/share/mysql/english/errmsg.sys having been modified to contain less than the number of entries needed.
i would get the installation/src files for mysql for your centos box again. Untar it and locate the file errmsg.sys from sql/share/english, copy it to /usr/share/mysql/english/errmsg.sys and restart your mysqld. Another option is just to reinstall mysql from centos repo, after backing up your dbs to make sure they don't get blown away and to have a copy/backup of it.
I would also find out what made the changes to the errmsg.sys file.