2 милиона бази данни? Предполагам, че имаш предвид "редове".
Както и да е, по отношение на ограниченията:едно от най-важните неща, които трябва да имате предвид е, че NDB/MySQL клъстерът не е база данни с общо предназначение. Най-вече операциите за присъединяване, но също и подзаявките и операциите за диапазон (заявки като:поръчки, създадени между сега и преди седмица), могат да бъдат значително по-бавни от това, което бихте очаквали. Това отчасти се дължи на факта, че данните се разпределят в множество възли. Въпреки че са направени някои подобрения, производителността на Join все още може да бъде много разочароваща.
От друга страна, ако трябва да се справите с много (за предпочитане малки) едновременни транзакции (обикновено актуализации на един ред/вмъкване/изтриване на справки по първичен ключ) и успявате да запазите всичките си данни в паметта, тогава това може да бъде много мащабируемо и производително решение.
Трябва да се запитате защо искате клъстер. Ако просто искате вашата обикновена база данни, която имате сега, освен с добавена 99,999% наличност, тогава може да бъдете разочаровани. Със сигурност MySQL клъстерът може да ви осигури голяма наличност и време за работа, но работното натоварване на вашето приложение може да не е много подходящо за нещата, за които клъстерът е добър. Освен това може да сте в състояние да използвате друго решение с висока наличност, за да увеличите времето на работа на вашата иначе традиционна база данни.
BTW - ето списък с ограничения съгласно документа:http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-limitations.html
Но каквото и да правите, изпробвайте клъстер, вижте дали е добре за вас. MySQL клъстерът не е "MySQL + 5 деветки". Ще разберете, когато опитате.