Can I use MySQL transactions on an InnoDB table inside MySQL event? Are there any restrictions on the event scheduler?
Following are limits on InnoDB Tables
Warning
Do not convert MySQL system tables in the mysql database from MyISAM to InnoDB tables! This is an unsupported operation. If you do this, MySQL does not restart until you restore the old system tables from a backup or re-generate them with the mysql_install_db script.
Warning
It is not a good idea to configure InnoDB to use data files or log files on NFS volumes. Otherwise, the files might be locked by other processes and become unavailable for use by MySQL.
**Go to follwoing link
restrictions on the event scheduler
Hope its help you!!!
Related
We have a script that "rotates"/archive the Syslog tables in MySQL. This script:
at Linux level, renames the "MyISAM" tables files then compress them
then
inside MySQL, rename these tables
The 2 steps are "online". No MySQLd restart is required.
Now I built a new Syslog database in MariaDB (Debian Stretch). The tables are using InnoDB and not MyISAM. This script fails at the 2nd execution to rename the table inside MySQL after moving the file:
ERROR 1050 (42S01): Table 'SystemEvents_1' already exists
A reference of the table is kept somewhere (tablespace internal system table?) which prevents from doing that.
My question:
would it work if I migrate my tables to the ARIA engine with transactional=0?
Thanks, Vince
I think it is no longer possible.
I converted my tables to MyISAM (and even Aria with transactional=0) and had the same error message. I think the best is to use mysqldump to export the tables instead of directly renaming the filesystem files. Less convenient but mysqldump will always work regardless the choosen engine.
I fairly new to MySQL database. I am repeatedly seeing an error from MySQL saying the table is marked as crashed and should be repaired. However I am able to repair the crashed table by using the command myisamchk. By the way, I am using MYISAM database engine in MySQL.
I just wanted to know under what circumstances would a DB table crash and how I can prevent it from happening again?
I am connecting to MySQL(5.0) database from Tcl (8.5) script using mysqltcl library (3.0).
MyISAM tables are very easy to crash. There is header info in each table that keeps track of how many open file handles a MyISAM table has.
If mysqld crashes, any MyISAM table that had open file handles to it never had the opportunity to decrement the file handle count upon each file handle closing. Thus, if a new file handle opens a MyISAM table (.MYD file) and mysqld discovers a mismatch between the number of file handles a MyISAM table believes is open and the the number of file handles the MyISAM table actually has open, the table is declared crashed.
There are four(4) methods for handling this:
METHOD #1 : Setup automatic MyISAM repair
See my post https://dba.stackexchange.com/a/15079/877 on how to set this up upon a MySQL restart (Mar 15, 2012)
METHOD #2 : Use InnoDB instead of MyISAM
InnoDB has crash recovery built into the Storage Engine's initialization. MyISAM does not
METHOD #3 : Use Aria instead of MyISAM
Aria is MariaDB's drop-in replacement for MyISAM. It features crash recovery mechanisms for individual tables.
METHOD #4 : Don't kill -9 on mysqld
If mysqld crashes, deliberately or involuntarily, header info for all open MyISAM tables will get them into a crashed state. Avoid having to manually kill mysqld.
I noticed that when I attempt to do a LVM snapshot of my database volume, after running FLUSH TABLES WITH READ LOCK, then rsync that snapshot to a new system, the tables are marked as crashed and have to be repaired.
I suspect this has to do with there being a file handle on the original machine with the table open, and then I'm syncing the that status to the new machine and it sees a mismatch in the file handles and decides it needs to repair.
This repair is problematic because it takes hours (it is a giant table). So the only reliable way to actually get a snapshot that isn't crashed is to shutdown the database before taking the snapshot, but then I cannot get the SHOW MASTER STATUS to setup replication.
An ARCHIVE table got corrupted in my production.
I tried
REPAIR TABLE TBL_NAME;
It wasn't able to repair the table. Does only MyISAM table support repairing?
I dropped the table, recreated it and then restored it from the dump I already had.
Q1: What could have been the better option to handle this scenario?
Q2: Why databases/tables getting corrupted so often?
Q3: What is the best that we could do to prevent tables from getting corrupt?
Q1: What could have been the better option to handle this scenario?
Given the circumstances I think that what you did was the best solution. There is an ARCHIVE engine recovery tool called archive_reader that might have been able to help you recover rows if you'd not had a backup
The fact that you had backups is good and saved you here. If you want to be able to perform a full recovery it could be worth enabling binary logging or adding a replicated slave server.
Q2: Why databases/tables getting corrupted so often?
In normal operation they shouldn't be. I would look in your MySQL error log to see if there are any error messages that corresponded to the time of the table crash. Disk or other problems on the server could make it more likely to corrupt tables. Perhaps you've found a bug in the ARCHIVE engine?
Q3: What is the best that we could do to prevent tables from getting corrupt?
As mentioned in Q2 have a good look for error messages. If you find that you can predictably replicate crashing a table be sure to file a MySQL bug report.
FOR MyISAM table:-
1) Identify all corrupted tables using myisamchk
2) Repair the corrupted table using myisamchk -r
If the tables are still getting used by your application and other tables.To avoid this error message, shutdown mysqld before performing the repair, if you can afford to shutdown the DB for a while. If not, use FLUSH TABLES to force mysqld to flush any table modification that are still in memory
You can also Perform check and repair together for entire MySQL database
Example :
myisamchk --silent --force --fast --update-state .....*.MYI
I'm the lucker owner of a webhotel where the host changes settings without telling.
When thats said,
I have some tables in my database that are running with InnoDB engine.
But over the night the host have disabled InnoDB, so I cant convert it to MyISAM with ALTER command.
Anyway I can get the data out of the database, or convert it to MyISAM when InnoDB is disabled?
Only thing I see all the time is,
#1033 - Incorrect information in file: 'file.frm'
Thanks.
Unfortunately, you need to have InnoDB enabled so that MySQL could read the data for conversion.
To recover the data on another instance, you would need ibdata* files from MySQL root data directory as well as all *.ibd files from your database directory (if your MySQL setup had innodb_file_per_table enabled).
I'm using MySQL 5.0.67 on RHEL5 and basing my configuration on my-huge.cnf.
I can't find anything in the MySQL manual for the row 'skip-locking' which appears in the config file.
Should this be replaced with 'skip_external_locking' or should I just remove the row entirely as that is now a default.
MySQL Manual for skip-external-locking
Thanks.
see http://dev.mysql.com/doc/refman/5.0/en/external-locking.html
quote:
If you run multiple servers that use the same database directory (not recommended), each server must have external locking enabled.
It really just has to do with the dangers presented by multiple processes accessing the same data. In many DBMS situations you want to lock the table/row before performing an operation, and unlocking afterwards. This is to prevent possible data corruption.
Edit: see http://dev.mysql.com/doc/refman/4.1/en/news-4-0-3.html
Quote
Renamed --skip-locking to --skip-external-locking.
An additional note for anyone who doesn't follow the link provided by #Jonathan Fingland :
8.7.4. External Locking
This option only applies to MyISAM tables.
As Richard indicated, external locking is disabled by default. You need to enable external locking if you use myisamchk for write operations or if you use myisampack to pack tables.
From the docs:
If you use myisamchk to perform table maintenance operations on MyISAM
tables, you must either ensure that the server is not running, or that
the server has external locking enabled so that it locks table files
as necessary to coordinate with myisamchk for access to the tables.
The same is true for use of myisampack to pack MyISAM tables.
If you use myisamchk for write operations such as repairing or
optimizing tables, or if you use myisampack to pack tables, you must
always ensure that the mysqld server is not using the table. If you
don't stop mysqld, you should at least do a mysqladmin flush-tables
before you run myisamchk. Your tables may become corrupted if the
server and myisamchk access the tables simultaneously.