Cassandra a horizontální škálování

[vesterna12]

Zdravím, pokukuju po Cassandře.
Libí se mí možnost horizontálního škálování.
Jediné co mi zatím není jasné je co se stane, když na nodu, který se stará i určitý oddíl dojde místo?
Přidáním nového nodu do clusteru sice vyrobím místo, ale není mi jasné jestli Cassandra automaticky rozšíří oddíl na nový nod nebo je potřeba změnit klíč, kterým se data do oddílů rozdělují? 
Pokud se klíč změní, začne Cassandra data přerozdělovat?

Pochopitelně, počet nových nodů  je dán replikačním faktorem.

[Reklama]

[tvojtatko]

ked pridas do clusteru novy node, tak to by defaut spravi toto:

1) kontaktuje seed nodes a zisti topologiu (gossip)
2) v nodetool budes vidiet stav UJ (Joining)
3) nauci sa to zo seedov aka je schema
4) ked sa node pripoji do clusteru, tak sa automaticky zmenia tokeny (tento novy node zacne vlastnit tokeny ostatnych nodov)
5) stream dat z ostatnych nodov na tento novy node podla tokenov ktory zacal ten novy node vlastnit
6) ked je hotovo status sa zmeni na UN

Takze pri pridani noveho node si proste ten novy node "stiahne" data k sebe a zmeni sa token ring.

Tie stare nody ale tie data ktore uz nevlastnia stale budu obsahovat. Tieto data musis z kazdeho nodu vymazat. To sa robit cez "nodetool clean".

Statistiky a progress streamingu zistis cez nodetool netstats


Predpokladam, ze mas nastavene "num_tokens: 16" ale podobne cislo (napr. 256, v neskorsich verziach sa zmenilo 256 na 16).

Ked toto nepouzivas a pouzivas "initial_token: ..." tak to je omnoho zlozitejsie kedze si tie tokeny musis komplet nakonfigurovat sam.

[tvojtatko]

Este by som dodal ze tvoja posledna veta "pocet nodov je dan replikacnim faktorem" nie je uplne spravna.

Ak mas cluster, ktory ma 50 nodov, tak tvoj RF nemusi byt 50. To sa v praxi vobec nerobi. Staci ak mas RF napriklad 3 alebo 5. Je jedno, ze ked ma cluster 9 nodov, tak to musi mat RF = 9, to nerob. RF = 3 staci.

Co je dolezite je tvoj consistency level ktory pouzivas pri queries.

Pri RF = 3 alebo 5 je dobre pouzit CL QUORUM. To znamena, ze vacsina nodov musi byt online aby tvoja query presla. (1 node z 3 moze byt offline resp. 2 nody z 5 pri RF = 5 a CL = QUORUM).

[vesterna12]

Díky za odpověď!
Nenapadlo by mě nastavit RF 50 v clusteru který má 50 nodů
3 v rámci "racku" stačí.
Ty 3 bych chtěl synchronní i za cenu, že si počkám na potvrzení všech.

Dá se nastavit asynchronní replikace pro nody, které jsou v jiném DC?

[tvojtatko]

Díky za odpověď!
Nenapadlo by mě nastavit RF 50 v clusteru který má 50 nodů
3 v rámci "racku" stačí.
Ty 3 bych chtěl synchronní i za cenu, že si počkám na potvrzení všech.

Dá se nastavit asynchronní replikace pro nody, které jsou v jiném DC?

ked mas RF = 3 a write robis s CL QUORUM, tak write coordinator caka len na dva zapisy z troch (quorum z 3 je 2) takze jeden node moze byt dole.

Az ked mas RF = 3 a CL = THREE tak to caka na vsetky. Nevyhoda THREE je, ze ked mas jeden node offline, tak cela query failne (pretoze to proste caka na tri uspesne zapisy).

Nic ako "synchronne a asynchronne zapisy do druheho DC" neexistuje. Okrem QUORUM mas este EACH_QUORUM. To znamena ze to zapise na kvorum nodov V KAZDOM DC. Normalne QUORUM mas quorum nodov cez vsetky nody a je jedno v akom DC.

Este existuje LOCAL_QUORUM. To znamena, ze to bude cakat len na zapisy v lokalnom DC (a len odtial bude citat) a koordinator bude vzdy node z toho DC.

Ak mas RF = 3, CL = QUORUM a jeden node je dole, tak query ako taka bude OK. Tie mutacie ktore sa nezapisu na ten node ktory je dole - pre tie sa ulozi tzv. HINT. Ked ten offline node znova rozbehnes, tak tie nody automaticky poslu tomu nodu co je naspat online vsetky hints. Je dobre potom spravit repair.

[Reklama]