NDB – Forced node shutdown completed. Caused by error 2341: ‘Internal program error (failed ndbrequire)

recently while working on MySQL cluster 7.3.5, we came across this error

Forced node shutdown completed. Caused by error 2341: 'Internal program error (failed ndbrequire)(Internal error, programming error or missing error message, please report a bug). Temporary error, restart node'.

The management nodes would start up but

the data nodes would complete phase 1 & shutdown, some times at phase 2 and some times at phase 5.

The error one would see in the trace file would be as follows:

Status: Temporary error, restart node
Message: Internal program error (failed ndbrequire) (Internal error, programming error or missing error message, please report a bug)
Error: 2341
Error data: CREATE_TABLE_REF
Error object: NDBCNTR (Line: 2493) 0x00000003
Program: ndbd

How did we resolve it ?

First, few of our data nodes had an incorrect connect-string

Second, we had pre-assigned NodeGroups for the data nodes in the config.ini, and had started our node groups with serial number 1.

[ndbd]

NodeGroupt=1

HostName=10.95.139.92

[ndbd]

NodeGroupt=2

HostName=10.95.139.92

Apparently, NDB likes to start up with serial number 0 onwards, so we changed  to

[ndbd]

NodeGroupt= 0

HostName=10.95.139.92

[ndbd]

NodeGroupt= 1

HostName=10.95.139.92

and walaa our cluster started up.

Thanks to Frank, for giving the work around (here).

Mobile Hack Day

Mobile Hack Day

its been a long time since i had a post on M*A*S*H and its nice to blog again.

Well yesterday, on August 7,  we had our HACK day and the theme was MOBILE.  I have participated in all flipkart hack days and i must tell you , they are simply awesome.

Last time the team ( Chetna/Anirudh/ Abhijat  & I )  went out to make Chota Minority Report (link here) and we had an awesome time. we won the Laziest but Effective Hack Award.

This time we set out to make something Different.  Since the Theme was MOBILE, we intended to do just that :)

How about making the MOBILE(noun) truly MOBILE (verb) !!!

Chetna & Anirdudh worked on the android app & Abhijat & I worked on the hardware.

We came up with 2 hacks.

The first is    Bhaag Mobile Bhaag  –  the mobile becomes mobile.

 

Bhaag Mobile Bhaag

THE  HACK  MOBILE

 

as per the theme , we made the mobile truly mobile :)

We made a mobile app (which we can control remotely) and this app flashes light.

once light hits the censor, the vehicle (which we programmed) starts moving. once light stops, the vehicle stops.

A video of mobility below :)

 

The second is called  “App Suicide

app suicide

A simple idea – with the motto –  “Customer First“,  the app cares for the customer and it is willing to save on battery for the customer.

All in all , a great hack day and we had fun.

Team:  Chetna/Anirudh/ Abhijat / Vishnu

PS: we work in the data platform on project Bigfoot @ flipkart

 

 

 

 

 

 

 

 

 

 

 

 

 

 

My talk @ Percona Live 2014

Will be giving a lightning talk at Percona Live 2014 – santa clara :)

In the world of replication, The Binlog is every ones favorite. 

But what about the Relay log, Don't you feel it can do more ?

Yes, It can. How about, if it can serve the purpose of the GTID 

feature without GTID.

https://www.percona.com/live/mysql-conference-2014/sessions/relay-log-unsung-hero

#MySQL  ( alternative to GTID )  #gtid

having a log table ?

I came across a scenario where we were concerned about the size of a table, a 134G table, its a pretty huge table and growing fast.
The nature of the table – its a table which contains logs , sort of a audit table.

Some fundamental questions around this table’s use:

1) would it have a lot of reads ?  — Answer –  No
2) is it always insert only? — Answer – Yes
3) current strategy to restrict size ? — Answer – delete data from table.
4) does one need backup of the table, i.e. is it very important ?  — Answer – No

Well based on the above, it would seem that logging is the theme.

Schema of the table:

CREATE TABLE `SystemLogs` (
  `column1` varchar(255) DEFAULT NULL,
  `column2` varchar(255) DEFAULT NULL,
  `column3` varchar(255) DEFAULT NULL,
  `column4` varchar(255) DEFAULT NULL,
  `column5` text,
  `column6` text,
  `timestamp` datetime DEFAULT NULL,
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `createdAt` datetime NOT NULL,
  `updatedAt` datetime NOT NULL,
  `column7` varchar(255) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_1` (`column1`,`column2`,`column3`)

) ENGINE=InnoDB

Some strategies to mitigate the concern:

Strategy-1
———-

Based on the above schema, most columns are TEXT / VARCHAR, which is a good case for

ROW COMPRESSION. This could be employed which would reduce the size of the table on disk.

The results of compression – yet to do some tests.
 
Strategy-2
———–

Since the table is use to hold logs, why not employ a logfile to hold such logs.
 
In the MySQL world, The Binlog could be used to do just that, its an audit log for all changes happening in the server.

Well, one would ask, if binlog logging is enabled, which was the case, as there is a master/slave arrangement,

then is that what we wanted to achieve ?

Yes, but partially,  the size of table on disk is the concern, the size does not decrease just because the binlog is enabled.

Here comes the change which will resolve the concern.

‘alter table SystemLogs engine=BLACKHOLE’.

So, when you insert into the table, now the entry will be made to the binlog keeping the size of the table on disk as 0 bytes.
 
If one wishes, one can reconstruct the table on another box (having its engine as innodb) by applying the binlog.
 
or

you can simply have a slave where the table has innodb engine and the table gets reconstructed there.