Around one week ago arrive a new update (10.1.30) after the update our system is recursively dying.
MariaDB dying and restarting at random time.
Some stored procedure calling get "Lost connection during query" error and restarting MariaDB. When debugging procedure then other unity dying the system.
Yesterday lost a table (.frm file going) this table is a Opencart product_description. But this table have only select query.
Error log only one InnoDB table marked as crashed. But this table i truncate... delete - recreate ... give to reaper... (:
We try to use MariaDB 10.2.xx but the problem not solved.
Thanks for answer.
Related
I'm having an issue with replication for two Mysql servers. The master is running Mysql 5.6 and the slave is running Mysql 8.0 due to another dependency that requires at least version 8. I am only replicating one DB, for this example's sake 'my_db'. However at a certain point in the day the master runs backups and tries to update the DB 'my_db_backups'. I am not replicating this DB and I just want to ignore these SQL commands on the replica. I explicitly ignore this database in my mysql.conf file using:
replicate-ignore-db=my_db_backups
However when I restart the mysql server I continue to see an error:
Last_SQL_Errno: 1049
Last_SQL_Error: Error 'Unknown database 'my_db_backups'' on query. Default database: 'my_db'. Query: 'INSERT INTO my_db.`table_1` SELECT * FROM my_db_backups.`2021_01_04_17_36_22_table_1`'
Everything I've read seems to indicate that setting replicate-do-db should only execute queries related to that DB. Additionally adding an explicit ignore, replicate-ignore-db, I would expect to work as well but I'm having no luck.
My full mysql.conf looks like this:
[mysqld]
server-id=20
lower_case_table_names=1
updatable_views_with_limit=1
relay-log-index=slave-relay-bin.index
relay-log=slave-relay-bin
replicate-ignore-db=my_db_backups
replicate-ignore-table=my_db.mysql_8_incompatible_view_1
replicate-ignore-table=my_db.mysql_8_incompatible_view_2
replicate-ignore-table=my_db.mysql_8_incompatible_view_3
replicate-ignore-table=my_db.mysql_8_incompatible_view_4
replicate-wild-do-table=my_db.%
replicate-do-db=my_db
I have tried every combination of these replicate-do and replicate-ignore-do configurations that I can think of I've tried adding:
replicate-wild-ignore-table=my_db_backups.%
and removing:
replicate-ignore-db=my_db_backups
and I've tried putting them both in the conf file. Nothing seems to work.
I know that I can explicitly skip error 1049 which is what I may have to end up doing. I'm just pulling my hair out trying to figure out why the other configurations aren't having any effect and can't let it go.
Any help would be greatly appreciated!
I noticed that the statement that produces the error isn't actually writing to a table in my_db_backups. It's replicating an INSERT to a table in my_db.
INSERT INTO my_db.`table_1` SELECT * FROM my_db_backups.`2021_01_04_17_36_22_table_1`
The statement is reading from a table in my_db_backups, which it did not find on the replica.
So the statement that inserts into my_db.table_1 will be executed on the replica, because the default database my_db was not ignored.
You could also fix this by using ROW-based binary logs on the master, so it doesn't matter that it's reading from a table that doesn't exist on the replica. The INSERT would result in a row image on the master, where the table does exist.
I run a web application on a shared LiteSpeed server with Mariadb version 10.3.22. I do have access to a terminal.
Cron is set up to perform a daily mysqldump, but I now get the error message:
mysqldump: Error 1412: Table definition has changed, please retry transaction when dumping table `TABLENAME` at row: 0
I do get a sql file, but it is a little smaller than it used to be. The table that is claimed to have changed it's definition is empty, just as it use to be (as far as I know).
I do not know much about mysql, and I do not understand the message "retry transaction when dumping table TABLENAME at row: 0"
Any clues about how to deal with that?
Please check the general log file of mysql service has "TRUNCATE" command on the table or not.
"TRUNCATE" command on the table during the mysqldump process changes table information and changing the command to "DELETE" command solved issue to me.
Default location of general log file is "/var/log/mysql/mysql.log" but it could be changed by "general_log_file" option and "general_log" option on "my.cnf" file.
If you are using mysql and getting error of "table defination has changed, please retry transaction " you have to do only one thing that is reconnect to DBMS, it will definitely solve the problem , tere is a button of "reconnect to DBMS" at home Page.
I have transferred MySQL community database into enterprise edition. When I'm trying to run Stored procedure or Function error occurred as column count is not match.
Sample query :
select `SPECIFIC_NAME`
from `INFORMATION_SCHEMA`.`ROUTINES`
where `ROUTINE_SCHEMA` = 'information_schema' and
ROUTINE_TYPE = 'PROCEDURE'
Error Message :
Column count of mysql.proc is wrong.
Expected 20, found 16. The table is probably corrupted
What changes can I do for recover from this issue.
You have transferred the mysql system database from your old server, and the two servers do not run the same version.
You might be able to recover the system tables with mysql_upgrade.
If not, try manually running the successive upgrade procedures from the version of your old server to the current version. Follow this link, you will find older upgrade procedures in the older versions of the manual on the left.
'm running a merge replication between two databases everything was fine. Starting from yesterday i'm getting this error message from replication job at Run Job step :
Executed as user: NT AUTHORITY\SYSTEM. String or binary data would be truncated. [SQLSTATE 22001] (Error 8152). The step failed.
What reasons can cause this error message ?
Please help.
A very very long stored procedure caused the problem as the replication went to update Altered procedures to the subscriber the changes. the column responsible for taking the Alter script was just (4000) characters capacity then the Alter script for this particular procedure didn't fit. rare case but happened !
We had a process that crashed while trying to manipulate an expected mysql record set, running the offending query from the mysql cli showed the following.
mysql> SELECT ...;
ERROR 1030: Got error 127 from table handler
Is there a way to easily recreate this condition so we can validate our fix ? (production DB was already repaired).
$ perror 127
OS error code 127: Key has expired
MySQL error code 127: Record file is crashed
The cause is most probably a corrupted MyISAM table ... I don't think it's possible to reproduce, unless you actually know how to provoke that corruption :/