No hardware this weekend due to delays by dell so only 2 nodes were migrated. Ran into another crappy Berkely DB issue where for no reason it would get stuck in native code.
at com.sleepycat.db.internal.db_javaJNI.Dbc_get(Native Method)
It was already 4:00 AM in the morning and I was pissed that Berkely db is giving last minute pains. In India they say "Bujhta Diya last main Tej Jalta hai" or "dying lantern runs more bright at end" . We tried doing a defrag of database but it didnt helped. Ultimately we moved the customer db to its own folder and then ran catastrophic recovery and restarted the migration. From past Berkely db migrations I had the experience that you would get these kind of issues and you might have to restart migrations. I had deliberately written the migration script in such a way that you can run it for 1 customer or 5 customer or all and restart migration in middle.
Anyway good news is that now one cluster in a DC has 160M rows and its going rocking fast.
There were no spikes reported by operations on nodes that are migrated to mysql. This ultimately leads to better customer satisfaction and even I can focus on more longer term tasks. Last 1 year has been frustrating with scaling Berkely db as I think we pushed both Berkely DB and NFS to its limits.