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 :/
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 keep getting this error when I try to start Artifactory: [art-init] [ERROR] (o.a.u.CommonDbUtils :57) - Failed to execute query: Table 'unique_ids' already exists:. I have tried renaming that table in mysql, however Artifactory then ran into another duplicate table:[art-init] [ERROR] (o.a.u.CommonDbUtils :57) - Failed to execute query: Table 'binaries' already exists:
When I tried restarting Artifactory after that it ran into the initial duplicate problem with the 'unique_ids' table, so it seems the solution is not to rename these duplicate tables as they are being created on start and Artifactory will continue to run into these duplicate errors every time it starts again after creating them.
Does anyone know why Artifactory keeps running into this problem and how I can make it stop?
Artifactory uses specific tables that it creates for itself (as part of its startup process). Perhaps something went wrong during said process and now it keeps trying to create the tables that it needs while they already exist. Wiping your database and restarting Artifactory should resolve the issue.
I have an issue where our database is receiving ~1000 updates a minute, and often we get an error response:
TAF: 1297 (HY000) at line 1: Got temporary error 899 'Rowid already allocated' from NDBCLUSTER
which appears in our application to our customer.
Is there any way to suppress these errors at the MySQL level? As I am not the developer of this application, I am not sure what language is performing the updates, but I presume either shell script or a C program.
I am using MySQL: 5.1.44-ndb-7.1.3-cluster-log (2 cluster nodes and 1 cluster mgmt node)
Have you tried using the 'IGNORE' clause in your SQL statements, the documentation for this is here
Using the IGNORE clause will downgrade errors to warnings, these warnings are displayed using the 'SHOW WARNINGS;' command
I am trying to migrate a test website on drupal onto a live server on Amazon ec2. I migrated the database using phpmyadmin, and tried to access the site. I got this error:
PDOException: SQLSTATE[42000]: Syntax error or access violation: 1286 Unknown table engine 'InnoDB': SELECT expire, value FROM {semaphore} WHERE name = :name; Array ( [:name] => variable_init ) in lock_may_be_available() (line 167 of /var/www/includes/lock.inc).
I believe the problem here is that MySQL doesn't have InnoDB. I have looked through the my.cnf file and there is no line that says skip-innodb.
I have tried show engines and it showed a bunch of engines but not innodb.
I have tried restarting my server and deleting the logfile, just like has been suggested previously, but that didn't work.
Maybe what needs to be done is to somehow install the Innodb engine. Could you tell me how I may do that?
On Debian 6 this can also happen when you change the innodb_log_file_size parameter... some times mysql does not start.. but other times it just starts up bud disables innodb engine... so solution is to remove ib_logfiles from /var/lib/mysql and restart mysql
Look in your mysql error log. Run
select ##log_error;
To see where exactly that is.
There is probably something in there telling why it failed on startup. (Perhaps trying to allocate more buffer pool than you have memory?)