Cassandra truncate не празни маси

Наскоро се сблъсках с този проблем. Когато попълних своите таблици (наречени събитие и индекс) на повече от 1 милион и се опитах да ги съкратя за нови тестове, таблиците не бяха празни след съкращаването. CQL показва нещо подобно

cqlsh> select count(*) from event limit 100000000;

 count
---------
 2033492


cqlsh> truncate event;
cqlsh> select count(*) from event limit 100000000;

 count
-------
    25

(1 rows)

cqlsh> select count(*) from event limit 100000000;

 count
-------
    27

(1 rows)

cqlsh> select count(*) from event limit 100000000;

 count
-------
    34

(1 rows)

cqlsh> select event_id, dateOf(time_token), unixTimestampOf(time_token), writetime(time_token) from event limit 100000000;

 event_id                             | dateOf(time_token)       | unixTimestampOf(time_token) | writetime(time_token)
--------------------------------------+--------------------------+-----------------------------+-----------------------
 567c4f2b-c86a-4663-a8ec-50f70d183b62 | 2014-07-22 22:29:04-0400 |               1406082544416 |      1406082544416000
 20a2f9e7-cdcb-4c2d-93e7-a646d0910e6b | 2014-07-22 15:12:29-0400 |               1406056349772 |      1406056349774000
 ... ...
 0d983cec-4ba5-4df8-ada8-eb347add57bf | 2014-07-22 22:20:53-0400 |               1406082053926 |      1406082053930000

(34 rows)

cqlsh>

След командата "truncate", "select count(*)" върна числа, които бързо се променяха и се стабилизираха на 34. За да съм сигурен, че няма друга програма, вмъкваща записи по това време, изпълних CQL израз, показващ, че всички записи са създадени на 22 или 23 юли, което е преди 4 - 5 дни.

Опитах командата "truncate" няколко пъти и резултатите бяха същите.

Това се случи в 2 среди. Първата среда е на моя лаптоп, където създадох 3 клъстера на екземпляри на Cassandra, използвайки IP адреси на локален хост (127.0.0.2, 127.0.0.3 и 127.0.0.4), докато втората среда е клъстер на Cassandra с 3 възела, като всеки възел е на отделен Linux CentOS 6.5 машина. Използвам Cassandra 2.0.6.

Може ли някой да ми помогне да разбера какво се случва? Благодаря предварително.


cassandra truncate
person dlu    schedule 28.07.2014    source източник

Отговори (3)


arrow_upward
4
arrow_downward

Това е грешка в Cassandra 2.0.6 и е коригирана поне в 2.0.10.

Очевидно това не е добре познат (добре публикуван) бъг, тъй като много експерти по DataStax също не го знаеха, когато им го възпроизведох на срещата на високо равнище Cassandra 2014. Те също бяха озадачени, докато архитектът на CQL не се отби и каза, че е поправил мистериозна грешка в скорошно издание. Той ме помоли да надстроя до 2.0.10 и проблемът изчезна. Няма повече бавни записи след „отрязване“ във 2.0.10.

person dlu    schedule 02.10.2014
comment
Не е коригирано за мен в 3.11.1. Трябваше да изключа клъстера и да го рестартирам след съкращаване, за да се отърва от фантомни редове, които продължаваха да се появяват отново след съкращаване. - person Scott Carey; 02.02.2018

arrow_upward
1
arrow_downward

Отрязването не съкращава подсказките, така че подсказките, чакащи доставка, пак ще бъдат доставени. Това може да е причина за вашия проблем, особено ако сте вмъкнали много редове бързо, което може да е причинило няколко отпаднали мутации. Подсказките обаче обикновено се доставят за минути, а не за дни, така че трябва да има нещо друго нередно, ако подсказките причиняват проблема ви. Можете да видите кога се доставят съвети от регистрационните файлове.

Най-сигурният начин да изтриете всички данни е да пуснете таблицата и да я създадете отново под друго име (или в различно пространство на ключове).

person Richard    schedule 29.07.2014

arrow_upward
0
arrow_downward

Има едно нещо, което абсолютно трябва да сте сигурни, преди да отрежете, че всички възли са готови.

Ако използвате Astyanax

/* променливата на ключовото пространство е тип на ключовото пространство */ keyspace.truncateColumnFamily(ColumnFamilyName);

Забележка: Дори след съкращаване ще трябва ръчно да изтриете всички метаданни на таблицата

person user3195649    schedule 28.07.2014
comment
Всичките 3 възела са готови със сигурност, тъй като 1) използвах състоянието на nodetool, за да проверя многократно и 2) последващата програма, която изисква LOCAL_QUORUM, е изпълнена успешно. Новите записи просто се добавят към таблиците върху тези записи, които не могат да бъдат съкратени. Между другото, използвам Java Driver 2 за моята програма. - person dlu; 29.07.2014