I am trying to backup a database using mysqldump but I got this error:
Trying to backup MySQL database... mysqldump: Couldn't execute 'show create table `transaction_registry`':
Table 'mysql.transaction_registry' doesn't exist in engine (1932)
the problem first were with innodb_index_stats & innodb_table_stats and followed the instructions and worked well but got another problem
I tried from these 1 - 2, but still getting the same error, any ideas?
what I ended doing is like that:
Removed corrupted tables:
rm -rf /var/lib/mysql/mysql/transaction_registry.idb
Recreated the table:
CREATE TABLE transaction_registry (
transaction_id bigint(20) unsigned NOT NULL,
commit_id bigint(20) unsigned NOT NULL,
begin_timestamp timestamp(6) NOT NULL DEFAULT '0000-00-00 00:00:00.000000',
commit_timestamp timestamp(6) NOT NULL DEFAULT '0000-00-00 00:00:00.000000',
isolation_level enum('READ-UNCOMMITTED','READ-COMMITTED','REPEATABLE-READ','SERIALIZABLE') COLLATE utf8_bin NOT NULL, PRIMARY KEY (transaction_id),
UNIQUE KEY commit_id (commit_id), KEY begin_timestamp (begin_timestamp), KEY commit_timestamp (commit_timestamp,transaction_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin STATS_PERSISTENT=0 ;
Ref: https://mariadb.com/kb/en/mysqltransaction_registry-table/
Related
I've a table with composite primary key with below structure:
CREATE TABLE field_name_test (
id_type varchar(128) NOT NULL DEFAULT '',
desc varchar(128) NOT NULL DEFAULT '' ,
deleted tinyint(4) NOT NULL DEFAULT '0' ,
type_id int(10) unsigned NOT NULL ,
rev_id int(10) unsigned NOT NULL ,
lang varchar(32) NOT NULL DEFAULT '',
delta int(10) unsigned NOT NULL,
fname_value varchar(255) DEFAULT NULL,
fname_format varchar(255) DEFAULT NULL,
PRIMARY KEY (id_type,type_id,rev_id,deleted,delta,lang),
KEY id_type (id_type),
KEY desc (desc),
KEY deleted (deleted),
KEY type_id (type_id),
KEY rev_id (rev_id),
KEY lang (lang),
KEY fname_format (fname_format)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
i'm running pt-o-s-c to change the collation of the table and it is working fine with other tables but this one is giving below error:
pt-online-schema-change --execute --password=#### --user=#### --socket=#### --port=#### --chunk-time=1 --recursion-method=none --no-drop-old-table --alter "CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci , CHANGE desc desc varchar(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci , CHANGE id_type id_type varchar(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci , CHANGE lang lang varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci , ROW_FORMAT=DYNAMIC , LOCK=SHARED, ALGORITHM=COPY" D=db,t=field_name_test,h=localhost
No slaves found. See --recursion-method if host ###### has slaves.
Not checking slave lag because no slaves were found and --check-slave-lag was not specified.
Operation, tries, wait:
copy_rows, 10, 0.25
create_triggers, 10, 1
drop_triggers, 10, 1
swap_tables, 10, 1
update_foreign_keys, 10, 1
Altering db.field_name_test...
Creating new table...
Created new table db._field_name_test_new OK.
Altering new table...
Altered db._field_name_test_new OK.
2017-09-15T09:18:47 Creating triggers...
2017-09-15T09:18:47 Created triggers OK.
2017-09-15T09:18:47 Copying approximately 3843064 rows...
2017-09-15T09:18:47 Dropping triggers...
2017-09-15T09:18:47 Dropped triggers OK.
2017-09-15T09:18:47 Dropping new table...
2017-09-15T09:18:47 Dropped new table OK.
db.field_name_test was not altered.
2017-09-15T09:18:47 Error copying rows from db.field_name_test to db._field_name_test_new: 2017-09-15T09:18:47 Error copying rows at chunk 1 of db.field_name_test because MySQL used only 390 bytes of the PRIMARY index instead of 497. See the --[no]check-plan documentation for more information.
I'm running above in Galera 3 node cluster.
So i've below concerns on pt-o-s-c:
1) what solutions can be for above such cases ?
2) Is it possible to run parallel pt-o-s-c in a same database ?
Please let me know if any other input you need. Thanks in advance.
Error
SQL query:
CREATE TABLE `wp_commentmeta` (
`meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`comment_id` bigint(20) unsigned NOT NULL DEFAULT '0',
`meta_key` varchar(255) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
`meta_value` longtext COLLATE utf8mb4_unicode_ci,
PRIMARY KEY (`meta_id`),
KEY `comment_id` (`comment_id`),
KEY `meta_key` (`meta_key`(191))
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
MySQL said: Documentation
#1050 - Table 'wp_commentmeta' already exists
I came across this issue and found that even if you drop the wp_commentmeta table, you are likely to have issues with other tables like wp_comments, wp_links etc.
Hence, the solution is just to drop the whole database, re-create a fresh one and restore to that. To do this, login to mysql:
mysql -u databaseuser -p
and then run the following command on your database:
drop database wordpress_database;
create database wordpress_database;
quit;
I had a similar issue and had to drop all the tables. Not recommended for the faint of heart. Make sure you have at least two different types of backups.
The error you are getting is pretty self explanatory!
You may think about executing the following SQL-Statement:
DROP TABLE wp_commentmeta;
I am exporting a mySQL database from one server to another. My export file contains all the table definitions, data, structure etc. All tables use the InnoDB engine and the utf8 charset. I am importing with the 'enable foreign key checks' switched off - my export file also has the line 'SET FOREIGN_KEY_CHECKS=0;'.
However, when I import the data, I get the error '#1215 - Cannot add foreign key constraint'
Here is the table definition in the input file:
CREATE TABLE IF NOT EXISTS UserTable (
Index_i int(13) NOT NULL,
UserUUID_vc varchar(36) DEFAULT NULL,
AccountID_i int(13) DEFAULT NULL,
FirstName_vc varchar(30) DEFAULT NULL,
LastName_vc varchar(40) DEFAULT NULL,
Password_vc varchar(255) DEFAULT NULL,
Country_vc varchar(2) DEFAULT NULL,
DateRegistered_dt timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
DateAccountTypeChanged_dt timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
DateAccountStatusChanged_dt timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
DateAcceptedTandC_dt timestamp NOT NULL DEFAULT '0000-00-00 00:00:00'
) ENGINE=InnoDB AUTO_INCREMENT=165 DEFAULT CHARSET=utf8;
It hits this problem before it reads any of the statements that apply constraints such as FK's to the table. In effect it doesn't know if any of these columns are foreign keys or not when it triggers the error message.
Any ideas?
If you're using terminal, login to mysql using your credentials with following command.
mysql -u[your_username] -p[your_password]
Set your mysql foreign key constraint checks to 0 using following command.
SET FOREIGN_KEY_CHECKS = 0;
Import your database using source command like below.
SOURCE /path/to/your/sql/file.sql
And set your mysql foreign key constraint checks back to 1 using following command.
SET FOREIGN_KEY_CHECKS = 1;
Hurrrrrraaaaah. Works like a charm. :)
P.S :- Tested on ubuntu 14.04, 16.04, 18.04
Add it as checkbox - disable foregin key check for this query in phpmyadmin to allow make changes on database
I am trying to alter one of my InnoDB tables.
This is query:
ALTER TABLE `tf5h_assets`
ADD PRIMARY KEY (`id`), ADD UNIQUE KEY `idx_asset_name` (`name`), ADD KEY `idx_lft_rgt` (`lft`,`rgt`), ADD KEY `idx_parent_id` (`parent_id`);
Error is:
#1114 - The table 'tf5h_assets' is full
I do not undesrtand how is it "full" when it's empty table i created from MySQL dump (structure, no data) file.
What's wierd is that i can alter it like this:
ALTER TABLE `tf5h_assets`
ADD PRIMARY KEY (`id`);
ALTER TABLE `tf5h_assets`
ADD UNIQUE KEY `idx_asset_name` (`name`);
ALTER TABLE `tf5h_assets`
ADD KEY `idx_lft_rgt` (`lft`,`rgt`);
ALTER TABLE `tf5h_assets`
ADD KEY `idx_parent_id` (`parent_id`);
and it does not throw that error.
What am i doing wrong?
This ALTER TABLE statements are from structure mysql dump file. Is there a way to split em like i did somehow when structure is exported so i dont have to do it manually?
I googles "table is full" error and this is what i did so far:
1) Checked for disk space - 80+ gigs of free space
2) Added to my.cnf :
innodb_file_per_table = 1
innodb_file_format = barracuda
and rebooted mysql server and created fresh db.
EDIT:
I solved my problem but i have no idea how to solve it for databases that i will not be able to export from Joomla.
Thing is, phpmyadmin is separating table creation from key creation like this:
CREATE TABLE IF NOT EXISTS `tf5h_assets` (
`id` int(10) unsigned NOT NULL COMMENT 'Primary Key',
`parent_id` int(11) NOT NULL DEFAULT '0' COMMENT 'Nested set parent.',
`lft` int(11) NOT NULL DEFAULT '0' COMMENT 'Nested set lft.',
`rgt` int(11) NOT NULL DEFAULT '0' COMMENT 'Nested set rgt.',
`level` int(10) unsigned NOT NULL COMMENT 'The cached level in the nested tree.',
`name` varchar(50) NOT NULL COMMENT 'The unique name for the asset.\n',
`title` varchar(100) NOT NULL COMMENT 'The descriptive title for the asset.',
`rules` varchar(5120) NOT NULL COMMENT 'JSON encoded access control.'
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=382 ;
and than later on:
ALTER TABLE `tf5h_assets`
ADD PRIMARY KEY (`id`), ADD UNIQUE KEY `idx_asset_name` (`name`), ADD KEY `idx_lft_rgt` (`lft`,`rgt`), ADD KEY `idx_parent_id` (`parent_id`);
and later on:
ALTER TABLE `tf5h_assets`
MODIFY `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Primary Key',AUTO_INCREMENT=382;
I managed to get my database up and running by using Joomla's backup / restore component (It's Joomla site). I opened up MySQL dump that component created and this is what i found in there:
CREATE TABLE `#__assets`
(`id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Primary Key',
`parent_id` int(11) NOT NULL DEFAULT '0' COMMENT 'Nested set parent.',
`lft` int(11) NOT NULL DEFAULT '0' COMMENT 'Nested set lft.',
`rgt` int(11) NOT NULL DEFAULT '0' COMMENT 'Nested set rgt.',
`level` int(10) unsigned NOT NULL COMMENT 'The cached level in the nested tree.',
`name` varchar(50) NOT NULL COMMENT 'The unique name for the asset.\n',
`title` varchar(100) NOT NULL COMMENT 'The descriptive title for the asset.',
`rules` varchar(5120) NOT NULL COMMENT 'JSON encoded access control.',
PRIMARY KEY (`id`),
UNIQUE KEY `idx_asset_name` (`name`),
KEY `idx_lft_rgt` (`lft`,`rgt`),
KEY `idx_parent_id` (`parent_id`) )
ENGINE=InnoDB AUTO_INCREMENT=382 DEFAULT CHARSET=utf8;
Whole process is executed in one run, and it works fine.
Now, i have luck it's Joomla database. But what will i do when database wont be Joomla's? I have no idea. Is there a way to change how phpmyadmin stores dump? Would terminal access to mysql create different mysql dump that would create database in one go instead of using "ALTER"?
Ok so i still don't know what creates this problem except that it has something to do with how phpmyadmin exports databases and reimports them again.
And as i assumed in my original post that i will run into this problem with database that can not be exported trough Joomla component sooner or later, it happened...well...sooner.
Anyway, if you have console access to your mysql server you can deal with this by simply mysql dumping:
mysqldump -p NameOfDatabase > NameOfDumpFile.sql
Download dump file from server and you can import it trough phpmyadmin. It works like a charm. mysqldump creates databases in one query so there is no problem with assigning keys etc.
Why do I get an error of the form:
Error in query: Duplicate entry '10' for key 1
...when doing an INSERT statement like:
INSERT INTO wp_abk_period (pricing_id, apartment_id) VALUES (13, 27)
...with 13 and 27 being valid id-s for existing pricing and apartment rows, and the table is defined as:
CREATE TABLE `wp_abk_period` (
`id` int(11) NOT NULL auto_increment,
`apartment_id` int(11) NOT NULL,
`pricing_id` int(11) NOT NULL,
`type` enum('available','booked','unavailable') collate utf8_unicode_ci default NULL,
`starts` datetime default NULL,
`ends` datetime default NULL,
`recur_type` enum('daily','weekly','monthly','yearly') collate utf8_unicode_ci default NULL,
`recur_every` char(3) collate utf8_unicode_ci default NULL,
`timedate_significance` char(4) collate utf8_unicode_ci default NULL,
`check_in_times` varchar(255) collate utf8_unicode_ci default NULL,
`check_out_times` varchar(255) collate utf8_unicode_ci default NULL,
PRIMARY KEY (`id`),
KEY `fk_period_apartment1_idx` (`apartment_id`),
KEY `fk_period_pricing1_idx` (`pricing_id`),
CONSTRAINT `fk_period_apartment1` FOREIGN KEY (`apartment_id`) REFERENCES `wp_abk_apartment` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION,
CONSTRAINT `fk_period_pricing1` FOREIGN KEY (`pricing_id`) REFERENCES `wp_abk_pricing` (`id`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
Isn't key 1 id in this case and having it on auto_increment sufficient for being able to not specify it?
Note: If I just provide an unused value for id, like INSERT INTO wp_abk_period (id, pricing_id, apartment_id) VALUES (3333333, 13, 27) it works fine, but then again, it is set as auto_increment so I shouldn't need to do this!
Note 2: OK, this is a complete "twilight zone" moment: so after running the query above with the huge number for id, things started working normally, no more duplicate entry errors. Can someone explain me WTF was MySQL doing to produce this weird behavior?
It could be that your AUTO_INCREMENT value for the table and the actual values in id column have got out of whack.
This might help:
Step 1 - Get Max id from table
select max(id) from wp_abk_period
Step 2 - Align the AUTO_INCREMENT counter on table
ALTER TABLE wp_abk_period AUTO_INCREMENT = <value from step 1 + 100>;
Step 3 - Retry the insert
As for why the AUTO_INCREMENT has got out of whack I don't know. Added auto_increment after data was in the table? Altered the auto_increment value after data was inserted into the table?
Hope it helps.
I had the same problem and here is my solution :
My ID column had a bad parameter. It was Tinyint, and MySql want to write a 128th line.
Sometimes, your problem you think the bigger you have is only a tiny parameter...
Late to the party, but I just ran into this tonight - duplicate key '472817' and the provided answers didn't help.
On a whim I ran:
repair table wp_abk_period
which output
Number of rows changed from 472816 to 472817
Seems like mysql had the row count wrong, and the issue went away.
My environment:
mysql Ver 14.14 Distrib 5.1.73, for Win64 (unknown)
Create table syntax:
CREATE TABLE `env_events` (
`tableId` int(11) NOT NULL AUTO_INCREMENT,
`deviceId` varchar(50) DEFAULT NULL,
`timestamp` int(11) DEFAULT NULL,
`temperature` float DEFAULT NULL,
`humidity` float DEFAULT NULL,
`pressure` float DEFAULT NULL,
`motion` int(11) DEFAULT NULL,
PRIMARY KEY (`tableId`)
) ENGINE=MyISAM AUTO_INCREMENT=528521 DEFAULT CHARSET=latin1
You can check the current value of the auto_increment with the following command:
show table status
Then check the max value of the id and see if it looks right. If not change the auto_increment value of your table.
When debugging this problem check the table name case sensitivity (especially if you run MySql not on Windows).
E.g. if one script uses upper case to 'CREATE TABLE my_table' and another script tries to 'INSERT INTO MY_TABLE'. These 2 tables might have different contents and different file system locations which might lead to the described problem.