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.
Related
I'm a new beginner about Mysql
When I initialize the database after executing an exe files, inserting data cannot be executed
Then I print a general log and try to find why, the insert statement is shown below and there is no detailed error information
enter image description here
However I check the error-log, there is no related information, and I try to run the same insert statement in command line and it can be executed.
So I want to why is it? Or at least let me know is there any error information
Thanks
Here is the code to open genral log in my.init:
log-bin=mysql-bin
binlog_format=mixed
log-output=FILE
general-log=1
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 have a query like this
UPDATE `database`.`user`
SET `Password`=Password("test1234!##$")
WHERE `UserID`='1234';
I ran this once and it updated the Password fine. I changed the case of the t in test and it started to fail with the message
Error Code: 1146. Table 'database.Unknown' doesn't exist.
After some experimentation I found that removing the $ in the string allowed the query to run successfully. I attempted to escape the character with / but the error still occurred. The collation on the column is utf8 and it is varchar(50).
The query itself is being executed in MySQL Workbench 5.2.47 and on MySQL version 5.1.62 Community Edition.
Can anyone enlighten me on why the $ is being troublesome.
EDIT: It is now occurring without any of the special characters. I also am aware there are much safer ways of hashing passwords. I am just curious at this point why the specific error is occurring.
First deduct the issue is from workbench:
Log in from command prompt (mysql -u Username -pPassword -h hostname) or with phpmyadmin and then try executing the query.
If that works, it's the workbench.
Then you might first want to just delete all configured connection settings in the workbench and re-adding them. This might already solve your problem.
If the problem maintains, you can try to re-install workbench.
Ended up being that a trigger existed that had this in it
INSERT INTO Unknown VALUES(1);
I don't know what the purpose of this is but it obviously was causing the issue. Thanks for the help regardless everyone.
'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 :/