Got error 66 "Object is remote" from storage engine InnoDB - mysql

I am running ALTER TABLE article_attachment CHANGE content content LONGBLOB NULL
on this table:
CREATE TABLE `article_attachment` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
`article_id` bigint(20) NOT NULL,
`filename` varchar(250) DEFAULT NULL,
`content_size` varchar(30) DEFAULT NULL,
`content_type` text,
`content_id` varchar(250) DEFAULT NULL,
`content_alternative` varchar(50) DEFAULT NULL,
`content` longblob NOT NULL,
`create_time` datetime NOT NULL,
`create_by` int(11) NOT NULL,
`change_time` datetime NOT NULL,
`change_by` int(11) NOT NULL,
`disposition` varchar(15) DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `article_attachment_article_id` (`article_id`),
KEY `FK_article_attachment_create_by_id` (`create_by`),
KEY `FK_article_attachment_change_by_id` (`change_by`)
) ENGINE=InnoDB AUTO_INCREMENT=34672 DEFAULT CHARSET=utf8
And get the error
Got error 66 "Object is remote" from storage engine InnoDB
Google returns almost nothing regarding the error.
I did increase max_allowed_packet to 999999488 but that did not help.
Update
I tried to change another column in the same table an there it tells me The size of BLOB/TEXT data inserted in one transaction is greater than 10% of redo log size. Increase the redo log size using innodb_log_file_size.
Maybe this is related...

Ok, I followed https://dba.stackexchange.com/a/1265/42097 and increased innodb_log_file_size in my.cnf mysqld section.
Mysql ANALYSE of the table told me article_attachment.content max_length is 22942326. So I set innodb_log_file_size to 300000000.
Now ALTER TABLE worked.

Related

mysql insert too slow and high io/cpu usage some time

the table row is about one hundred million, sometimes the io bps about 150
IOPS about 4k
os version: CentOS Linux 7
MySQL version: docker mysql:5.6
server_id=3310
skip-host-cache
skip-name-resolve
max_allowed_packet=20G
innodb_log_file_size=1G
init-connect='SET NAMES utf8mb4'
character-set-server = utf8mb4
collation-server = utf8mb4_general_ci
innodb_flush_log_at_trx_commit=0
innodb_buffer_pool_size=5120M
expire-logs-days=7
log_bin=webser
binlog_format=ROW
back_log=1024
slow_query_log
slow_query_log_file=slow-log
tmpdir=/var/log/mysql
sync_binlog=1000
the create table statement
CREATE TABLE `device_record` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`os` tinyint(9) DEFAULT NULL,
`uid` int(11) DEFAULT '0',
`idfa` varchar(50) DEFAULT NULL,
`adv` varchar(8) DEFAULT NULL,
`oaid` varchar(100) DEFAULT NULL,
`appId` tinyint(4) DEFAULT NULL,
`agent` varchar(100) DEFAULT NULL,
`channel` varchar(20) DEFAULT NULL,
`callback` varchar(1500) DEFAULT NULL,
`activeAt` datetime DEFAULT NULL,
`chargeId` int(11) DEFAULT '0',
`createAt` datetime DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `idfa_record_index_oaid` (`oaid`),
UNIQUE KEY `index_record_index_agent` (`agent`) USING BTREE,
UNIQUE KEY `idfa_record_index_idfa_appId` (`idfa`) USING BTREE,
KEY `index_record_index_uid` (`uid`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1160240883 DEFAULT CHARSET=utf8mb4
insert statement
#Insert(
"insert into idfa_record (os,idfa,oaid,appId,agent,channel,callback,adv,createAt) "
+ "values(#{os},#{idfa},#{oaid},#{appId},#{agent},#{channel},#{callback},#{adv},now()) on duplicate key "
+ "update createAt=if(uid<=0,now(),createAt),activeAt=if(uid<=0 and channel != #{channel},null,activeAt),channel=if(uid<=0,#{channel},channel),"
+ "adv=if(uid<=0,#{adv},adv),callback=if(uid<=0,#{callback},callback),appId=if(uid<=0,#{appId},appId)")
100M rows, but the auto_increment is already at 1160M? This is quite possible, but...
Most importantly, the table is more than halfway to overflowing INT SIGNED.
Are you doing inserts that "burn" ids?
Does the existence of 4 Unique keys cause many rows to be skipped?
This seems excessive: max_allowed_packet=20G.
How much RAM is available?
Does swapping occur?
How many rows are inserted per second? What is "bps"? (I am pondering why there are 4K writes. I would expect about 2 IOPS per Unique key per INSERT, but that dones not add up to 4K unless you have about 500 Inserts/sec.
Are the Inserts coming from different clients? (This feeds into "burning" ids, sluggishness, etc.)

MySQL, table requires to run "optimize" command too often

I have a table that is growing about 200MB/hour.
If I run the optimize command on it, the size is reduced to 2MB and start growing again.
The table is a WordPress installation with very few visits (~100/day).
I was wondering if there is something wrong with this table, this is the table schema:
CREATE TABLE `wpii_options` (
`option_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`option_name` varchar(191) NOT NULL DEFAULT '',
`option_value` longtext NOT NULL,
`autoload` varchar(20) NOT NULL DEFAULT 'yes',
PRIMARY KEY (`option_id`),
UNIQUE KEY `option_name` (`option_name`)
) ENGINE=InnoDB AUTO_INCREMENT=16525 DEFAULT CHARSET=utf8
MySQL version 5.5.49-cll-lve
If unnecessary, try to reduce to:
bigint(20) -> int(20)
longtext -> text

Slow Updates for Single Records by Primary Key

I am using MySQL 5.5.
I have an InnoDB table definition as follows:
CREATE TABLE `table1` (
`col1` int(11) NOT NULL AUTO_INCREMENT,
`col2` int(11) DEFAULT NULL,
`col3` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`col4` int(11) DEFAULT NULL,
`col5` datetime DEFAULT NULL,
`col6` tinyint(1) NOT NULL DEFAULT '0',
`col7` datetime NOT NULL,
`col8` datetime NOT NULL,
`col9` int(11) DEFAULT NULL,
`col10` tinyint(1) NOT NULL DEFAULT '0',
`col11` tinyint(1) DEFAULT '0',
PRIMARY KEY (`col1`),
UNIQUE KEY `index_table1_on_ci_ai_tn_sti` (`col2`,`col4`,`col3`,`col9`),
KEY `index_shipments_on_applicant_id` (`col4`),
KEY `index_shipments_on_shipment_type_id` (`col9`),
KEY `index_shipments_on_created_at` (`col7`),
KEY `idx_tracking_number` (`col3`)
) ENGINE=InnoDB AUTO_INCREMENT=7634960 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
The issue is UPDATES. There are about 2M rows in this table.
A typical UPDATE query would be :
UPDATE table1 SET col6 = 1 WHERE col1 = 7634912;
We have about 5-10k QPS on this production server. These queries are often in "Updating" state when looked at through the process list. The InnoDB locks show that there are many rec but not gap locks on index_table1_on_ci_ai_tn_sti. No transaction is waiting for lock.
My feeling is that the Unique Index is causing the lag but I'm not sure why. This is the only table we have that is defined this way using the Unique Index.
I don't think the UNIQUE key has any impact (in this case).
Are you really setting a DATETIME to "1"? (Please check for other typos -- they could make a big difference.)
Are you trying to do 10K UPDATEs per second?
Is innodb_buffer_pool_size bigger than the table, but no bigger than 70% of available RAM?
What is the value of innodb_flush_log_at_trx_commit? 1 is default and secure, but slower than 2.
Can you put a bunch of updates into a single transaction? That would cut down the transaction overhead.

MySQL 5.1 to 5.5 upgrade causes significant write slowdown (MyISAM + indexes)

We just upgraded from MySQL 5.1 to 5.5. An insert script that used to take ~3 mins to insert ~200k rows into a MyISAM table with 3 indexes now takes ~8 mins! Removing the indexes solves the issue!?
Reads(selects) are fine (faster in 5.5 than 5.1)
Is something different about index behavior or could there be some oddball config parameter that may need to be tweaked?
Thanks in advance for any pointers!
System Info:
Fedora 17, Mysql 5.5.29-log, 16GB RAM
MyISAM Key Buffer = 4GB
MyISAM index size = ~800 MB
MyISAM table size = 4.4 GB
INNODB Buffer Pool = 8GB
INNODB table+index size = ~12GB
Here's the table definition per request:
CREATE TABLE MY_TABLE
( MY_TABLE_ID int(10) unsigned NOT NULL AUTO_INCREMENT,
FIELD_1 char(1) NOT NULL,
FIELD_2 int(11) NOT NULL,
FIELD_3 varchar(64) NOT NULL,
FIELD_4 varchar(64) DEFAULT NULL,
FIELD_5 varchar(64) DEFAULT NULL,
FIELD_6 varchar(8) DEFAULT NULL,
FIELD_7 varchar(64) DEFAULT NULL,
FIELD_8 varchar(64) DEFAULT NULL,
FIELD_9 varchar(64) DEFAULT NULL,
FIELD_10 varchar(16) DEFAULT NULL,
FIELD_11 varchar(124) DEFAULT NULL,
FIELD_12 varchar(124) DEFAULT NULL,
FIELD_13 varchar(124) DEFAULT NULL,
FIELD_14 varchar(32) DEFAULT NULL,
FIELD_15 varchar(32) DEFAULT NULL,
FIELD_16 varchar(64) DEFAULT NULL,
FIELD_17 varchar(64) DEFAULT NULL,
FIELD_18 varchar(64) DEFAULT NULL,
FIELD_19 varchar(64) DEFAULT NULL,
FIELD_20 char(1) DEFAULT NULL,
FIELD_21 text,
FIELD_22 text,
FIELD_23 text,
FIELD_24 varchar(32) DEFAULT NULL,
FIELD_25 varchar(64) DEFAULT NULL,
FIELD_26 varchar(16) DEFAULT NULL,
FIELD_27 varchar(64) DEFAULT NULL,
FIELD_28 varchar(64) DEFAULT NULL,
FIELD_29 text,
FIELD_30 int(11) NOT NULL,
FIELD_31 varchar(16) DEFAULT NULL,
FIELD_32 varchar(16) DEFAULT NULL,
CREATION_DATE int(11) NOT NULL,
MODIFICATION_DATE timestamp NULL DEFAULT NULL,
PRIMARY KEY (MY_TABLE_ID),
KEY I_FIELD_4 (FIELD_4),
KEY I_FIELD_2 (FIELD_2),
KEY I_FIELD_3 (FIELD_3)
) ENGINE=MyISAM DEFAULT CHARSET=latin1
Well, after lots of troubleshooting, the issue was narrowed down to bad drives. Not MySQL 5.5. Everything is fine now with different drives..
RAM is too crowded.
For 16GB RAM and a mixture of InnoDB and MyISAM:
key_buffer_size = 1600M
innodb_buffer_pool_size = 6G

MySql performance suggestions

I am not MySQL expert and am stuck in a problem. I have a table which currently hold 16GB of data and it will grow further. The structure of the table is given below,
CREATE TABLE `t_xyz_tracking` (
`id` BIGINT(20) NOT NULL AUTO_INCREMENT,
`word` VARCHAR(200) NOT NULL,
`xyzId` BIGINT(100) NOT NULL,
`xyzText` VARCHAR(800) NULL DEFAULT NULL,
`language` VARCHAR(2000) NULL DEFAULT NULL,
`links` VARCHAR(2000) NULL DEFAULT NULL,
`xyzType` VARCHAR(20) NULL DEFAULT NULL,
`source` VARCHAR(1500) NULL DEFAULT NULL,
`sourceStripped` TEXT NULL,
`isTruncated` VARCHAR(40) NULL DEFAULT NULL,
`inReplyToStatusId` BIGINT(30) NULL DEFAULT NULL,
`inReplyToUserId` INT(11) NULL DEFAULT NULL,
`rtUsrProfilePicUrl` TEXT NULL,
`isFavorited` VARCHAR(40) NULL DEFAULT NULL,
`inReplyToScreenName` VARCHAR(40) NULL DEFAULT NULL,
`latitude` BIGINT(100) NOT NULL,
`longitude` BIGINT(100) NOT NULL,
`rexyzStatus` VARCHAR(40) NULL DEFAULT NULL,
`statusInReplyToStatusId` BIGINT(100) NOT NULL,
`statusInReplyToUserId` BIGINT(100) NOT NULL,
`statusFavorited` VARCHAR(40) NULL DEFAULT NULL,
`statusInReplyToScreenName` TEXT NULL,
`screenName` TEXT NULL,
`profilePicUrl` TEXT NULL,
`xyzId` BIGINT(100) NOT NULL,
`name` TEXT NULL,
`location` VARCHAR(200) NULL DEFAULT NULL,
`bio` TEXT NULL,
`url` TEXT NULL COLLATE 'latin1_swedish_ci',
`utcOffset` INT(11) NULL DEFAULT NULL,
`timeZone` VARCHAR(100) NULL DEFAULT NULL,
`frenCnt` BIGINT(20) NULL DEFAULT '0',
`createdAt` DATETIME NULL DEFAULT NULL,
`createdOnGMT` VARCHAR(40) NULL DEFAULT NULL,
`createdOnServerTime` DATETIME NULL DEFAULT NULL,
`follCnt` BIGINT(20) NULL DEFAULT '0',
`favCnt` BIGINT(20) NULL DEFAULT '0',
`totStatusCnt` BIGINT(20) NULL DEFAULT NULL,
`usrCrtDate` VARCHAR(200) NULL DEFAULT NULL,
`humanSentiment` VARCHAR(30) NULL DEFAULT NULL,
`replied` BIT(1) NULL DEFAULT NULL,
`replyMsg` TEXT NULL,
`classified` INT(32) NULL DEFAULT NULL,
`createdOnGMTDate` DATETIME NULL DEFAULT NULL,
PRIMARY KEY (`id`),
INDEX `id` (`id`, `word`),
INDEX `word_index` (`word`) USING BTREE,
INDEX `classified_index` (`classified`) USING BTREE,
INDEX `createdOnGMT_index` (`createdOnGMT`) USING BTREE,
INDEX `location_index` (`location`) USING BTREE,
INDEX `word_createdOnGMT` (`word`, `createdOnGMT`),
INDEX `timeZone` (`timeZone`) USING BTREE,
INDEX `language` (`language`(255)) USING BTREE,
INDEX `source` (`source`(255)) USING BTREE,
INDEX `xyzId` (`xyzId`) USING BTREE,
INDEX `getunclassified_index` (`classified`, `xyzType`) USING BTREE,
INDEX `createdOnGMTDate_index` (`createdOnGMTDate`, `word`) USING BTREE,
INDEX `links` (`links`(255)) USING BTREE,
INDEX `xyzType_classified` (`classified`, `xyzType`) USING BTREE,
INDEX `word_createdOnGMTDate` (`word`, `createdOnGMTDate`) USING BTREE
)COLLATE='utf8_general_ci'
ENGINE=InnoDB
ROW_FORMAT=DEFAULT
AUTO_INCREMENT=17540328
The queries on this table are running slow now and I am expecting them to slow down further, my server configuration is given below,
Intel Xeon E5220 #2.27GHz (2 processors)
12GB Ram
Windows 2008 Server R2
my.ini file details are given below,
default-storage-engine=INNODB
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
max_connections=300
query_cache_size=0
table_cache=256
tmp_table_size=205M
thread_cache_size=8
myisam_max_sort_file_size=3G
myisam_sort_buffer_size=410M
key_buffer_size=354M
read_buffer_size=64K
read_rnd_buffer_size=256K
sort_buffer_size = 64M
join_buffer_size = 64M
thread_cache_size = 8
thread_concurrency = 8
query_cache_size = 128M
innodb_additional_mem_pool_size=15M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=30M
innodb_buffer_pool_size=6G
innodb_log_file_size=343M
innodb_thread_concurrency=44
max_allowed_packet = 16M
slow_query_log
long_query_time = 6
What can be done to improve performance,
Would converting to MyISAM table help, I have INNODB since this table has frequent write and even more frequent reads.
I have noticed high disk I/O, at time as high as 20-40MB/sec
Thanks,
Rohit
One suggestion is to run
SELECT * FROM t_xyz_tracking PROCEDURE ANALYSE()
PROCEDURE ANALYSE will tell you, based on the data in the table, the suggested types for the columns in the table. This should help increase your efficiency.
All the NULLable columns could be potentially moved to a separate table. Check what percentage of values in each of these columns is NULL, and if it's relatively high - move it to a separate table.
Next you might want to think which columns are accessed very often, and which ones are accessed relatively rarely. Rarely used columns can be moved to a separate table as well.
When your mysql server is too slow, a good idea is to activate the "slow query log", and then study the queries showing up in it.
This has helped me a lot to avoid some possible catastrophic failures due to some amateurish written queries.
Just off the top of my head, it looks like you're using the TEXT type where you shouldn't. TEXT is a CLOB (think BLOB for characters only). If you have a url, VARCHAR(255) might work better. For a name, isn't 50 characters enough?
The queries that are running slow, are they utilizing the indexes?
Could your "isXXX" fields be changed to BOOLEAN (or tinyint(1))?