John, can you provide some more info so we can fix the problems? See below.
John Stile wrote:
>Using mysql-max-4.1.7-pc-linux-i686 on Debian stable, 2GB RAM, with dual
>2.4G Xeon, running MGM, NDB, and API with 2 replicas.
>
>I ported the schema of a LAMP email application named 'messenger' to
>mysql cluster (all TYPE=MyISAM to ENGINE=NDBCLUSTER). Loading data
>still in progress, but I should report my finding thus far. See
>http://www.worldwidecreations.com for the 'messenger' company's website.
>
>Loading the schema generated
> 163 UserTables
> 54 OrderedIndex
> 27 UniqueHashIndexs
> 135 IndexTriggers
> 81 HashIndexTriggers
>
>Some issues with NDB were uncovered during the port:
> * LINGERING ARTIFACTS FROM A FAILED CREATE
> * LONGBLOBS
> * LONG RECORDS
> * SPECIFY UNIQUE ON PRIMARY KEY CAUSED ERRORS
>
>After a failed create of one table, the table appears in ndb_show_tables
>but not in mysql 'show tables'. I tried to clear the table without
>success with ndb_drop_table and dropping the database. I had to
>reinitialize the ndbd node to clear the table with 'echo <node> restart
>-i' | ndb_mgm. Any attempt to alter or read the ghost table resulted in
>the error:
> ERROR 1005 (HY000): Can't create table './somedomain_com_messenger/popmail.frm'
> (errno: 156)
>
>
>
Can you reproduce this an provide the create table statement that fails?
>There seems to be a problem with 'longblob' and 'longtext' with
>ENGINE=NDB, but converting both to 'mediumblob' allowed the schema to
>load. The error looks like:
> ERROR 1005: Can't create table './somedomain_com_messenger/statistics.frm' (errno:
> 4242)
>
>
>
You had run out of available indexes, you'd have had to increase a
config parameter.
see perror --ndb 4242
Error code 4242: Too many indexes: Permanent error: Application error
>I had to convert 'varchar(255)' to 'tinytext' to get past the error:
> ERROR 1118: Row size too large. The maximum row size for the used table type, not
> counting BLOBs, is 4092. You have to change some columns to TEXT or BLOBs
>
>
>
should be 8k from 4.1.8
>On several tables, where 'UNIQUE KEY `PRI` (`id`)' was set on the
>already 'PRIMARY KEY (`id`)' resulted in a load error. Removing the
>UNIQUE line allowed the schema to load. From what I have been told.,
>
>
>since the primary is already unique, unique was redundant.
>
>
Can you provide some create table constructs that fail so we can fix it.
BR,
Tomas
>
>
>
