'cassandra' 카테고리의 글 목록 (4 Page)

[cassandra] 클라이언트 라이브러리 하위 호환성 지원 (cassandra java driver compatibility)

cassandra 2017. 2. 23. 16:17

hbase 클라이언트 사용 할 때, hbase 서버와의 버전을 반드시 확인해야 프로토콜 이슈가 없다.

하지만, cassandra는 최상위 버전인 3.1.4 버전의 클라이언트 라이브러를 사용해도 일부 하위 버전까지 하위 호환성을 유지한다..

The Java client driver 3.1.4 (branch 3.1) is compatible with Apache Cassandra 1.2, 2.0, 2.1, 2.2 and 3.0 (see this pagefor the most up-to-date compatibility information).

http://datastax.github.io/java-driver/manual/native_protocol

Native protocol

The native protocol defines the format of the binary messages exchanged between the driver and Cassandra over TCP. As a driver user, you don’t need to know the fine details (although the protocol spec is in the Cassandra codebase if you’re curious); the most visible aspect is that some features are only available with specific protocol versions.

Compatibility matrix

By default, the protocol version is negotiated between the driver and Cassandra when the first connection is established. Both sides are backward-compatible with older versions:

	Cassandra: 1.2.x (DSE 3.2)	2.0.x (DSE 4.0 to 4.6)	2.1.x (DSE 4.7)	2.2.x	3.0.x
Driver: 1.0.x	v1	v1	v1	v1	Unsupported (1)
2.0.x to 2.1.1	v1	v2	v2	v2	Unsupported (1)
2.1.2 to 2.1.x	v1	v2	v3	v3	Unsupported (2)
3.x	v1	v2	v3	v4	v4

(1) Cassandra 3.0 does not support protocol versions v1 and v2

(2) There is a matching protocol version (v3), but the driver 2.1.x can’t read the new system table format of Cassandra 3.0

For example, if you use version 2.1.5 of the driver to connect to Cassandra 2.0.9, the maximum version you can use (and the one you’ll get by default) is protocol v2 (third row, second column). If you use the same version to connect to Cassandra 2.1.4, you can use protocol v3.

netty 버전과 이슈가 있을 수 있으니.아래 내용도 참고한다.

https://github.com/datastax/java-driver/tree/3.1.x/manual/shaded_jar

참고로 cassandra 2.1에서 3.1로 올리는 테스트해보니 바로 되지 않는 부분이 있다.

LocalDate의 getTime 메소드 같은 경우는 아예 사라져 있다.

long startDate = row.getDate("date1").getTime();

다음과 같은 에러가 발생했다.

(188): Codec not found for requested operation: [timestamp <-> com.datastax.driver.core.LocalDate]

com.datastax.driver.core.exceptions.CodecNotFoundException: Codec not found for requested operation: [timestamp <-> com.datastax.driver.core.LocalDate]

at com.datastax.driver.core.CodecRegistry.notFound(CodecRegistry.java:679) ~[story-app.jar:na]

at com.datastax.driver.core.CodecRegistry.createCodec(CodecRegistry.java:526) ~[story-app.jar:na]

at com.datastax.driver.core.CodecRegistry.findCodec(CodecRegistry.java:506) ~[story-app.jar:na]

at com.datastax.driver.core.CodecRegistry.access$200(CodecRegistry.java:140) ~[story-app.jar:na]

at com.datastax.driver.core.CodecRegistry$TypeCodecCacheLoader.load(CodecRegistry.java:211) ~[story-app.jar:na]

at com.datastax.driver.core.CodecRegistry$TypeCodecCacheLoader.load(CodecRegistry.java:208) ~[story-app.jar:na]

at com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3524) ~[story-app.jar:na]

at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2317) ~[story-app.jar:na]

at com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2280) ~[story-app.jar:na]

at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2195) ~[story-app.jar:na]

at com.google.common.cache.LocalCache.get(LocalCache.java:3934) ~[story-app.jar:na]

at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3938) ~[story-app.jar:na]

at com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4821) ~[story-app.jar:na]

at com.datastax.driver.core.CodecRegistry.lookupCodec(CodecRegistry.java:480) ~[story-app.jar:na]

at com.datastax.driver.core.CodecRegistry.codecFor(CodecRegistry.java:448) ~[story-app.jar:na]

at com.datastax.driver.core.CodecRegistry.codecFor(CodecRegistry.java:430) ~[story-app.jar:na]

at com.datastax.driver.core.AbstractGettableByIndexData.codecFor(AbstractGettableByIndexData.java:69) ~[story-app.jar:na]

at com.datastax.driver.core.AbstractGettableByIndexData.getDate(AbstractGettableByIndexData.java:174) ~[story-app.jar:na]

at com.datastax.driver.core.AbstractGettableData.getDate(AbstractGettableData.java:26) ~[story-app.jar:na]

at com.datastax.driver.core.AbstractGettableData.getDate(AbstractGettableData.java:111) ~[story-app.jar:na]

다음 코드로 변경하면 잘 동작한다.

row.getTimestamp("date1").getTime();

좋은 자료

https://groups.google.com/a/lists.datastax.com/forum/#!topic/java-driver-user/pAoLlEzmGWA

https://datastax-oss.atlassian.net/browse/JAVA-1176

maven dependency 3.1과 2.1 비교

cassandra 3.1

[INFO] +- com.datastax.cassandra:cassandra-driver-core:jar:3.1.3:compile

[INFO] | +- io.netty:netty-handler:jar:4.0.37.Final:compile

[INFO] | | +- io.netty:netty-buffer:jar:4.0.37.Final:compile

[INFO] | | | \- io.netty:netty-common:jar:4.0.37.Final:compile

[INFO] | | +- io.netty:netty-transport:jar:4.0.37.Final:compile

[INFO] | | | \- (io.netty:netty-buffer:jar:4.0.37.Final:compile)

[INFO] | | \- io.netty:netty-codec:jar:4.0.37.Final:compile

[INFO] | | \- (io.netty:netty-transport:jar:4.0.37.Final:compile)

[INFO] | +- (com.google.guava:guava:jar:16.0.1:compile)

[INFO] | +- io.dropwizard.metrics:metrics-core:jar:3.1.2:compile

[INFO] | | \- (org.slf4j:slf4j-api:jar:1.7.7:compile - omitted for conflict with 1.7.6)

[INFO] | +- com.github.jnr:jnr-ffi:jar:2.0.7:compile

[INFO] | | +- com.github.jnr:jffi:jar:1.2.10:compile

[INFO] | | +- com.github.jnr:jffi:jar:native:1.2.10:runtime

[INFO] | | +- (org.ow2.asm:asm:jar:5.0.3:compile - omitted for conflict with 4.1)

[INFO] | | +- (org.ow2.asm:asm-commons:jar:5.0.3:compile - omitted for conflict with 4.1)

[INFO] | | +- org.ow2.asm:asm-analysis:jar:5.0.3:compile

[INFO] | | | \- (org.ow2.asm:asm-tree:jar:5.0.3:compile)

[INFO] | | +- org.ow2.asm:asm-tree:jar:5.0.3:compile

[INFO] | | | \- (org.ow2.asm:asm:jar:5.0.3:compile - omitted for conflict with 4.1)

[INFO] | | +- org.ow2.asm:asm-util:jar:5.0.3:compile

[INFO] | | | \- (org.ow2.asm:asm-tree:jar:5.0.3:compile)

[INFO] | | \- com.github.jnr:jnr-x86asm:jar:1.0.2:compile

[INFO] | \- com.github.jnr:jnr-posix:jar:3.0.27:compile

[INFO] | +- (com.github.jnr:jnr-ffi:jar:2.0.7:compile)

[INFO] | \- com.github.jnr:jnr-constants:jar:0.9.0:compile

cassandra 2.1

[INFO] +- com.datastax.cassandra:cassandra-driver-core:jar:2.1.9:compile

[INFO] | +- io.netty:netty-handler:jar:4.0.27.Final:compile

[INFO] | | +- io.netty:netty-buffer:jar:4.0.27.Final:compile

[INFO] | | | \- io.netty:netty-common:jar:4.0.27.Final:compile

[INFO] | | +- io.netty:netty-transport:jar:4.0.27.Final:compile

[INFO] | | | \- (io.netty:netty-buffer:jar:4.0.27.Final:compile)

[INFO] | | \- io.netty:netty-codec:jar:4.0.27.Final:compile

[INFO] | | \- (io.netty:netty-transport:jar:4.0.27.Final:compile)

[INFO] | +- (com.google.guava:guava:jar:14.0.1:compile - omitted for conflict with 16.0.1)

[INFO] | \- com.codahale.metrics:metrics-core:jar:3.0.2:compile

[INFO] | \- (org.slf4j:slf4j-api:jar:1.7.5:compile - omitted for conflict with 1.7.6)

저작자표시

'cassandra' 카테고리의 다른 글

[cassandra] cassandra 3.0.9 설치 (0)	2017.03.17
[cassandra] 설정 수정 주의 (0)	2017.03.17
cassandra gc 튜닝 - compaction과 full gc (0)	2017.02.17
[cassandra] node subrange repair 작업 - 범위 단위로 repairing 하기 (0)	2017.01.31
[cassandra] node repair 처리 방식 (0)	2017.01.31

Posted by '김용환'

,

cassandra gc 튜닝 - compaction과 full gc

cassandra 2017. 2. 17. 18:15

cassandra를 운영하면서 CMS Full GC가 발생하면서 수십 초동안 stop the world (hang)이 발생했다. 이를 간단히 해결한 내용을 작성한다.

Case #1

node repair를 하고 난 직후 바로 다른 table(colum family)에서 compaction이 일어났고 CMS Full GC가 발생했다.

수십 초동안 stop the world (hang)이 발생했다.

<system.log>

INFO [MemtableFlushWriter:30358] 2017-02-10 19:18:38,616 Memtable.java:382 - Completed flushing /var/lib/cassandra/data/googleplus/activity_counts-2b2d7da08ec211e6aa074b983626f83b/googleplus-activity_counts-tmp-ka-199677-Data.db (5.208MiB) for commitlog position ReplayPosition(segmentId=1483928416854, position=30283693)

INFO [Service Thread] 2017-02-10 19:23:54,659 GCInspector.java:252 - ParNew GC in 371ms. CMS Old Gen: 3756257272 -> 4008698560; Par Eden Space: 1718091776 -> 0; Par Survivor Space: 99052984 -> 214695936

INFO [Service Thread] 2017-02-10 19:24:03,365 GCInspector.java:252 - ParNew GC in 206ms. CMS Old Gen: 5184283352 -> 5516390704; Par Eden Space: 1718091776 -> 0;

INFO [Service Thread] 2017-02-10 19:24:03,767 GCInspector.java:252 - ParNew GC in 223ms. CMS Old Gen: 5516390704 -> 5851059920; Par Eden Space: 1718091776 -> 0;

INFO [Service Thread] 2017-02-10 19:24:33,346 GCInspector.java:252 - ParNew GC in 21623ms. CMS Old Gen: 5851059920 -> 6084658992;

INFO [Service Thread] 2017-02-10 19:24:33,346 StatusLogger.java:51 - Pool Name Active Pending Completed Blocked All Time Blocked

INFO [Service Thread] 2017-02-10 19:24:33,385 StatusLogger.java:66 - MutationStage 96 837 2082221481 0 0

INFO [Service Thread] 2017-02-10 19:24:33,388 StatusLogger.java:66 - RequestResponseStage 0 0 3415222266 0 0

INFO [Service Thread] 2017-02-10 19:24:33,388 StatusLogger.java:66 - ReadRepairStage 0 0 129691312 0 0

INFO [Service Thread] 2017-02-10 19:24:33,388 StatusLogger.java:66 - CounterMutationStage 14 0 61697119 0 0

INFO [Service Thread] 2017-02-10 19:24:33,388 StatusLogger.java:66 - ReadStage 40 23 1525495767 0 0

INFO [Service Thread] 2017-02-10 19:24:33,389 StatusLogger.java:66 - MiscStage 0 0 0 0 0

INFO [Service Thread] 2017-02-10 19:24:33,389 StatusLogger.java:66 - AntiEntropySessions 0 0 30954 0 0

INFO [Service Thread] 2017-02-10 19:24:33,389 StatusLogger.java:66 - HintedHandoff 0 1 4704 0 0

INFO [Service Thread] 2017-02-10 19:24:33,389 StatusLogger.java:66 - GossipStage 0 0 9002749 0 0

INFO [Service Thread] 2017-02-10 19:24:33,389 StatusLogger.java:66 - CacheCleanupExecutor 0 0 0 0 0

INFO [Service Thread] 2017-02-10 19:24:33,389 StatusLogger.java:66 - InternalResponseStage 0 0 27677 0 0

INFO [Service Thread] 2017-02-10 19:24:33,389 StatusLogger.java:66 - CommitLogArchiver 0 0 0 0 0

INFO [Service Thread] 2017-02-10 19:24:33,390 StatusLogger.java:66 - CompactionExecutor 2 65 3178052 0 0

INFO [Service Thread] 2017-02-10 19:24:33,390 StatusLogger.java:66 - ValidationExecutor 0 0 772255 0 0

INFO [Service Thread] 2017-02-10 19:24:33,390 StatusLogger.java:66 - MigrationStage 0 0 7 0 0

INFO [Service Thread] 2017-02-10 19:24:33,390 StatusLogger.java:66 - AntiEntropyStage 0 0 6186269 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,357 MessagingService.java:888 - 1 REQUEST_RESPONSE messages dropped in last 5000ms

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,396 StatusLogger.java:51 - Pool Name Active Pending Completed Blocked All Time Blocked

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,396 StatusLogger.java:66 - MutationStage 96 2022 2082221481 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,396 StatusLogger.java:66 - RequestResponseStage 0 0 3415222266 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,396 StatusLogger.java:66 - ReadRepairStage 0 0 129691312 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,397 StatusLogger.java:66 - CounterMutationStage 14 0 61697119 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,397 StatusLogger.java:66 - ReadStage 43 329 1525495974 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,397 StatusLogger.java:66 - MiscStage 0 0 0 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,397 StatusLogger.java:66 - AntiEntropySessions 0 0 30954 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,397 StatusLogger.java:66 - HintedHandoff 0 1 4704 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,397 StatusLogger.java:66 - GossipStage 0 0 9002749 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,398 StatusLogger.java:66 - CacheCleanupExecutor 0 0 0 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,398 StatusLogger.java:66 - InternalResponseStage 0 0 27677 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,398 StatusLogger.java:66 - CommitLogArchiver 0 0 0 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,398 StatusLogger.java:66 - CompactionExecutor 2 65 3178052 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,398 StatusLogger.java:66 - ValidationExecutor 0 0 772255 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,398 StatusLogger.java:66 - MigrationStage 0 0 7 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,399 StatusLogger.java:66 - AntiEntropyStage 0 0 6186269 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,399 StatusLogger.java:66 - PendingRangeCalculator 0 0 11 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,399 StatusLogger.java:66 - Sampler 0 0 0 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,399 StatusLogger.java:66 - MemtableFlushWriter 0 0 284744 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,399 StatusLogger.java:66 - MemtablePostFlush 1 1 969941 0 0

INFO [ScheduledTasks:1] 2017-02-10 19:24:33,399 StatusLogger.java:66 - MemtableReclaimMemory 0 0 361430 0 0

WARN [GossipTasks:1] 2017-02-10 19:24:33,423 FailureDetector.java:249 - Not marking nodes down due to local pause of 30438450773 > 5000000000

INFO [GossipTasks:1] 2017-02-10 19:24:33,423 Gossiper.java:968 - InetAddress /1.1.1.1 is now DOWN

INFO [GossipTasks:1] 2017-02-10 19:24:33,426 Gossiper.java:968 - InetAddress /1.1.1.2 is now DOWN

INFO [GossipTasks:1] 2017-02-10 19:24:33,427 Gossiper.java:968 - InetAddress /1.1.1.3 is now DOWN

INFO [GossipTasks:1] 2017-02-10 19:24:33,427 Gossiper.java:968 - InetAddress /1.1.1.4 is now DOWN

INFO [GossipTasks:1] 2017-02-10 19:24:33,427 Gossiper.java:968 - InetAddress /1.1.1.5 is now DOWN

INFO [GossipTasks:1] 2017-02-10 19:24:33,427 Gossiper.java:968 - InetAddress /1.1.1.6 is now DOWN

INFO [GossipTasks:1] 2017-02-10 19:24:33,428 Gossiper.java:968 - InetAddress /1.1.1.7 is now DOWN

...

INFO [MemtableFlushWriter:30358] 2017-02-10 19:18:38,616 Memtable.java:382 - Completed flushing /var/lib/cassandra/data/googleplus/activity_counts-2b2d7da08ec211e6aa074b983626f83b/googleplus-activity_counts-tmp-ka-199677-Data.db (5.208MiB) for commitlog position ReplayPosition(segmentId=1483928416854, position=30283693)

INFO [Service Thread] 2017-02-10 19:23:54,659 GCInspector.java:252 - ParNew GC in 371ms. CMS Old Gen: 3756257272 -> 4008698560; Par Eden Space: 1718091776 -> 0; Par Survivor Space: 99052984 -> 214695936

INFO [Service Thread] 2017-02-10 19:24:03,365 GCInspector.java:252 - ParNew GC in 206ms. CMS Old Gen: 5184283352 -> 5516390704; Par Eden Space: 1718091776 -> 0;

INFO [Service Thread] 2017-02-10 19:24:03,767 GCInspector.java:252 - ParNew GC in 223ms. CMS Old Gen: 5516390704 -> 5851059920; Par Eden Space: 1718091776 -> 0;

INFO [Service Thread] 2017-02-10 19:24:33,346 GCInspector.java:252 - ParNew GC in 21623ms. CMS Old Gen: 5851059920 -> 6084658992;

Number Of Blocks이 굉장히 낮았음에도 불구하고 old gen이 여유가 있음에도 CMS Full GC가 발생했다.

<gc.log>

2017-02-10T19:24:03.543+0900: 2793841.374: [GC (Allocation Failure) Before GC:

Statistics for BinaryTreeDictionary:

------------------------------------

Total Free Space: 61954108

Max Chunk Size: 56091256

Number of Blocks: 281

Av. Block Size: 220477

Tree Height: 24

2793841.375: [ParNew

Desired survivor size 107347968 bytes, new threshold 1 (max 1)

- age 1: 214016272 bytes, 214016272 total

: 1887488K->209664K(1887488K), 0.2227276 secs] 7274588K->5923589K(8178944K)After GC:

Statistics for BinaryTreeDictionary:

------------------------------------

Total Free Space: 23251391

Max Chunk Size: 23251391

Number of Blocks: 1

Av. Block Size: 23251391

Tree Height: 1

, 0.2230334 secs] [Times: user=2.82 sys=0.00, real=0.22 secs]

Heap after GC invocations=262308 (full 750):

par new generation total 1887488K, used 209664K [0x00000005c0000000, 0x0000000640000000, 0x0000000640000000)

eden space 1677824K, 0% used [0x00000005c0000000, 0x00000005c0000000, 0x0000000626680000)

from space 209664K, 100% used [0x0000000626680000, 0x0000000633340000, 0x0000000633340000)

to space 209664K, 0% used [0x0000000633340000, 0x0000000633340000, 0x0000000640000000)

concurrent mark-sweep generation total 6291456K, used 5713925K [0x0000000640000000, 0x00000007c0000000, 0x00000007c0000000)

Metaspace used 38684K, capacity 39508K, committed 39740K, reserved 1085440K

class space used 4042K, capacity 4201K, committed 4216K, reserved 1048576K

}

2017-02-10T19:24:03.766+0900: 2793841.598: Total time for which application threads were stopped: 0.2254495 seconds, Stopping threads took: 0.0007439 seconds

{Heap before GC invocations=262308 (full 750):

par new generation total 1887488K, used 1887488K [0x00000005c0000000, 0x0000000640000000, 0x0000000640000000)

eden space 1677824K, 100% used [0x00000005c0000000, 0x0000000626680000, 0x0000000626680000)

from space 209664K, 100% used [0x0000000626680000, 0x0000000633340000, 0x0000000633340000)

to space 209664K, 0% used [0x0000000633340000, 0x0000000633340000, 0x0000000640000000)

concurrent mark-sweep generation total 6291456K, used 5713925K [0x0000000640000000, 0x00000007c0000000, 0x00000007c0000000)

Metaspace used 38684K, capacity 39508K, committed 39740K, reserved 1085440K

class space used 4042K, capacity 4201K, committed 4216K, reserved 1048576K

2017-02-10T19:24:03.966+0900: 2793841.798: [GC (Allocation Failure) Before GC:

Statistics for BinaryTreeDictionary:

------------------------------------

Total Free Space: 23251391

Max Chunk Size: 23251391

Number of Blocks: 1

Av. Block Size: 23251391

Tree Height: 1

2793841.798: [ParNew (0: promotion failure size = 4) (1: promotion failure size = 15) (2: promotion failure size = 14) (3: promotion failure size = 8194) (4: promotion failure size = 15) (5: promotion failure size = 36) (6: promotion failure size = 4) (7: promotion failure size = 14) (8: promotion failure size = 8229) (9: promotion failure size = 14) (10: promotion failure size = 14) (11: promotion failure size = 4) (12: promotion failure size = 35) (13: promotion failure size = 4) (14: promotion failure size = 15) (15: promotion failure size = 4) (16: promotion failure size = 14) (17: promotion failure size = 8194) (promotion failed): 1887488K->1887488K(1887488K), 21.6232257 secs]2793863.422: [CMS2017-02-10T19:24:26.299+0900: 2793864.131: [CMS-concurrent-mark: 2.053/24.445 secs] [Times: user=128.39 sys=13.12, real=24.44 secs]

(concurrent mode failure)CMS: Large block 0x00000006ad3f4960

: 5942049K->1789778K(6291456K), 7.7547756 secs] 7601413K->1789778K(8178944K), [Metaspace: 38684K->38684K(1085440K)]After GC:

Statistics for BinaryTreeDictionary:

------------------------------------

Total Free Space: 576198356

Max Chunk Size: 576198356

Number of Blocks: 1

Av. Block Size: 576198356

Tree Height: 1

, 29.3783154 secs] [Times: user=106.14 sys=4.60, real=29.38 secs]

Heap after GC invocations=262309 (full 751):

par new generation total 1887488K, used 0K [0x00000005c0000000, 0x0000000640000000, 0x0000000640000000)

eden space 1677824K, 0% used [0x00000005c0000000, 0x00000005c0000000, 0x0000000626680000)

from space 209664K, 0% used [0x0000000633340000, 0x0000000633340000, 0x0000000640000000)

to space 209664K, 0% used [0x0000000626680000, 0x0000000626680000, 0x0000000633340000)

concurrent mark-sweep generation total 6291456K, used 1789778K [0x0000000640000000, 0x00000007c0000000, 0x00000007c0000000)

Metaspace used 38684K, capacity 39508K, committed 39740K, reserved 1085440K

class space used 4042K, capacity 4201K, committed 4216K, reserved 1048576K

}

2017-02-10T19:24:33.345+0900: 2793871.177: Total time for which application threads were stopped: 29.3870599 seconds, Stopping threads took: 0.0070944 seconds

2017-02-10T19:24:33.348+0900: 2793871.180: Total time for which application threads were stopped: 0.0018513 seconds, Stopping threads took: 0.0002945 seconds

2017-02-10T19:24:33.357+0900: 2793871.188: Total time for which application threads were stopped: 0.0062973 seconds, Stopping threads took: 0.0002382 seconds

2017-02-10T19:24:33.375+0900: 2793871.206: Total time for which application threads were stopped: 0.0132915 seconds, Stopping threads took: 0.0113025 seconds

원인

young gen(from, to, eden) 영역의 데이터를 old gen으로 못 올리는 이슈가 있었다.

wide row도 영향이 있는 상태라 판단했다.

# case 2

SNS 서비스의 hotspotting 사용자(친구가 많은 사용자)가 글을 쓸 때 cassandra에서 timeout이 발생하기도 했고 어쩔 때는 한 번에 많은 사용자가 hotspotting 사용자의 데이터를 읽으면서 #case 1처럼 young 영역에서 CMS full gc가 발생했다.

이 문제를 해결하기 위해 gc를 간단히 튜닝했는데, 바로 문제가 해결되었다.

아래는 hotspotting 사용자가 글을 썼을 때 사용자들이 반응하였다. full gc와 full gc로 인한 cpu가 튀는 것을 볼 수 있다.

cassandra의 전체 메모리를 좀 늘리고 (8G -> 12G), -XX:CMSInitiatingOccupancyFraction의 값을 35로 낮췄다.

즉 young gen 영역을 높여서 node repair 이후의 compaction 이슈와 hotspotting 사용자의 데이터 때문에 cassandra가 흔들리지 않도록 했다. 아래와 같이 특정 사용자가 글을 써도 크게 영향을 주지 않음을 알 수 있었다.

그리고 -XX:CMSWaitDuration=10000를 -XX:CMSWaitDuration=100으로 나춰 최대한 gc 시간으로 인해서 튀는 일이 없도록 했다.

어떤 상황이 와도 full gc는 50~60ms가 나오도록 했다.

더 이상 cassandra는 흔들리지 않고 있다.

최대한 memory를 확보할 뿐 아니라 cassandra 질의할 때 최대한 데이터를 많이 얻는 구조(네트워크 용량 및 데이터를 얻음으로서 jvm 데이터 방지)도 조정하는 것이 좋을 것 같다.

또한 재시작 이후에 node간 copy가 일어나서 부하가 높아질 뿐 아니라, compaction이 발생한다. 특히 wide row 테이블 쪽에서 operationtimeout이 발생할 수 있으니, 유의하기 바란다.

참고로 cassandra 종료 스크립트이다.

nodetool disablegossip

sleep 2

nodetool disablethrift

sleep 2

nodetool drain

sleep 2

jps | grep CassandraDaemon | awk {'print $1'} | xargs kill -9

참고로 cassandra 시작 스크립트이다.

CASSANDRA_CONF=/etc/cassandra/conf cassandra

저작자표시

'cassandra' 카테고리의 다른 글

[cassandra] 설정 수정 주의 (0)	2017.03.17
[cassandra] 클라이언트 라이브러리 하위 호환성 지원 (cassandra java driver compatibility) (0)	2017.02.23
[cassandra] node subrange repair 작업 - 범위 단위로 repairing 하기 (0)	2017.01.31
[cassandra] node repair 처리 방식 (0)	2017.01.31
[cassandra] 백업 - nodetool snapshot (0)	2017.01.31

Posted by '김용환'

,

[cassandra] node subrange repair 작업 - 범위 단위로 repairing 하기

cassandra 2017. 1. 31. 14:15

이 글을 보기 전에 먼저 봐야할 문서

http://knight76.tistory.com/entry/cassandra-node-repair-%EC%B2%98%EB%A6%AC-%EB%B0%A9%EC%8B%9D

cassandra 노드를 reparing하는 방법 중 가장 오래 걸리지만 서비스에 영향을 주지 않는 방법인 subrange repair 방법을 소개한다.

우선 nodetool을 이용해 토큰 정보를 살펴본다.

$ nodetool ring

Datacenter: datacenter1

==========

Address Rack Status State Load Owns Token

9211576253984633484

1.1.1.1 rack1 Up Normal 3.19 GB 100.00% -9143017454602368711

1.1.1.2 rack1 Up Normal 3.19 GB 100.00% -9137016989552942674

,,

subrange를 사용하려면 계산하고 이런 작업이 귀찮아서 오픈소스를 확인했더니,https://github.com/BrianGallew/cassandra_range_repair.git(https://github.com/BrianGallew/cassandra_range_repair/blob/master/src/range_repair.py)가 괜찮을 것 같다. 특히 dry run모드가 있어서 테스트해볼 수 있는 장점이 있다 (단점으로는 중간에 중지시키는게 번거롭다. for 문에서 continue되어 다음 토큼으로 넘어가기기 때문에 kill로 작업해야 한다)

https://github.com/BrianGallew/cassandra_range_repair/blob/master/src/range_repair.py는 python 2.6이면 six 모듈 때문에 문제가 될 수 있으니. python 2.7.9로 업그레이드해야 한다.

git clone https://github.com/BrianGallew/cassandra_range_repair.git를 해서 ./src/range_repair.py을 실행한다.

이 스크립트로 dry-run 모드로 실행해 본다.

./range_repair.py -k google -v -d -H localhost --dry-run 를 실행한다. 토큰이 제대로 되는지 확인했다.

0001/1/256 nodetool -h localhost -p 7199 repair google -pr -st +09211576253984633484 -et +09212497757635858978

0002/1/256 nodetool -h localhost -p 7199 repair google -pr -st +09212497757635858978 -et +09213419261287084472

..

0100/256/256 nodetool -h localhost -p 7199 repair google -pr -st +09211440617066457144 -et +09211576253984633484

로그 파일은 다음과 같이 추가한다.

--logfile test.log

테이블 단위로 repairing할 수 있다.

./range_repair.py -k story -c 테이블_이름 -d -H localhost

시간이 오래 걸려서 screen 실행하고 백그라운드로 작업 돌리는 것이 좋을 것 같다.

상황에 따라서는 너무 오래 걸리기도 하고, 부하를 줘서 latency가 커질 수 있어서 부하가 적은 시간에 여러 날에 걸쳐 동작시켜야 할 수도 있다.

저작자표시

'cassandra' 카테고리의 다른 글

[cassandra] 클라이언트 라이브러리 하위 호환성 지원 (cassandra java driver compatibility) (0)	2017.02.23
cassandra gc 튜닝 - compaction과 full gc (0)	2017.02.17
[cassandra] node repair 처리 방식 (0)	2017.01.31
[cassandra] 백업 - nodetool snapshot (0)	2017.01.31
cassandra table 변경 (0)	2017.01.26

Posted by '김용환'

,

[cassandra] node repair 처리 방식

cassandra 2017. 1. 31. 14:14

대용량 cassandra를 운영한다는 것은 좀 공부가 필요한 것 같다. redis 이상의 운영 노하우가 필요한 것 같다.

특히 compaction이나 node repair를 하다가 cassandra를 읽는 부분에서 timeout나고 에러 뜨고 장난아니다.

dry-run 이런 옵션이 nodetool에 없기에 공부를 반드시 많이하고 다른 곳에서는 compaction을 어떻게 하는지 살펴볼 필요가 있다.

cassandra는 3가지 동기화 방식을 가진다.

cassandra 전문 용어로 Hinted Hand-off, Read-Repair, Anti-Entropy Repair이다.

이 중 Anti-Entropy Repair 방식은 수동으로 동작시키는 nodetool repair를 말한다.

node repair를 실행하면 가장 먼저 coordinator 노드는 데이터를 기준으로 primary와 복제본 파티션 정보를 얻기 위해 각 노드마다 요청하고 Merkle 트리를 구성하려 한다. 마침 요청받은 카산드라 노드(peer node)는 SSTable을 스캔해서 유효성 검사를 진행하고 major compaction(SSTable의 모든 row를 읽고 해시를 생성한다)을 실행시켜 Merkle tree의 구성을 완료하면 Merkle 트리의 기반이 되는 데이터를 coodinator node에 전달한다. coodinator node는 모든 Merkle 트리를 모든 트리와 비교해, 차이를 발견하면(해시 비교) 서로 다른 노드간에 데이터가 교환된다.

<참고>

Merkle 트리 : 잎은 데이터이고, 상위 노드는 자식 노드의 해시 값으로 구성된 이진 트리

p2p나 cassandra과 같은 형태의 데이터 구조에서 해시의 변조를 통해 데이터가 바뀌었는지를 쉽게 알 수 있다.

(참고 : https://docs.datastax.com)

Merkle 트리를 구성하기 위해서는 SSTable을 모두 읽기 때문에 cpu, memory, disk i/o, network inbound/outbound가 급격하게 올라간다. 또한 데이터의 불일치가 많이 발생하면 network 비용이 올라간다.

node repair 방식을 설명하기 전에 아래 아래 디폴트 설정을 잠깐 본다. reparing은 2가지 관점이 필요하다. 처음에 cassandra reparing을 공부할 때 헤매기도 한다.

Full <--> Increment

Parrallel <--> Sequentail

http://www.datastax.com/dev/blog/repair-in-cassandra

Cassandra 1.2 introduced a new option to repair to help manage the problems caused by the nodes all repairing with each other at the same time, it is call a snapshot repair, or sequential repair. As of Cassandra 2.1, sequential repair is the default, and the old parallel repair an option

http://docs.datastax.com/en/archived/cassandra_win/3.x/cassandra/tools/toolsRepair.html

Incremental repair is the default for Cassandra 2.2 and later, and full repair is the default in Cassandra 2.1 and earlier. In Cassandra 2.2 and later, when a full repair is run, SSTables are marked as repaired and anti-compacted. Parallel repair is the default for Cassandra 2.2 and later, and sequential repair is the default in Cassandra 2.1 and earlier.

따라서 2.1 cassandra의 default repairing 정책은 full, sequential repair이다!!

1. primary range repair

0.x부터 있던 옵션으로 오래된 방식의 repairing 방식으로, primary node(커맨드를 실행한 노드)만 repair가 일어난다. 다른 노드에서 작업할려면 다른 노드 서버로 로그인하고 repair 커맨드를 실행해야 한다. 잘 안쓴다.

2. sequential repair

snapshot repair라기도 한다. 전체 노드에 대해서 순차적으로 repairing을 시도한다. 부하가 좀 낮기 때문에 괜찮다. 2.1의 default 정책이다.

3. parrallel repair

repair 옵션에 -par을 추가한 경우이다. 동시(concurrently)에 Merkle 트리를 구성하도록 모든 노드에 명령을 내린다. 빨리 repairing이 되지만 모든 부하가 커져서 요청 데이터를 받지 못할 수 있다. cassandra의 모든 데이터가 서비스에서 카산드라를 사용하는 중에 -par을 사용하면 애플리케이션 바로 hang이 된 것처럼 타임아웃이 발생한다. (서비스용도라면 절대로 사용하지 말아야 한다)

4. Incremental repair

2.1부터 추가된 옵션으로 증분 reparing을 지원한다. 2.2부터 default이다. (아직 안써봤다!)

leveled compaction strategy를 사용할 때 incremental repair를 할 때는 에러가 발생할 수 있다고 한다(https://issues.apache.org/jira/browse/CASSANDRA-9935). 또한 incremental repair를 사용하면 leveled compaction strategy에서 sizedTierStrategy로 바뀐다고 하니, 운영 노하우를 알면 좋을 듯 하다.

5. subrange repair

primary range repair와 같지만, 시작 토큰 값(start token)과 마지막 토큰 값(end token)을 정의할 수 있는 유연성을 가지고 있다. "-st" (or "–start-token") 와 "-et" (or “–end-token”) 를 사용한다. 많이 느리긴 하지만 부하를 줄이고 서비스의 안정성을 확보한다는 점에서 좋은 것 같다.

subrange repair 작업은 http://knight76.tistory.com/entry/cassandra-node-subrange-repair-%EC%9E%91%EC%97%85-%EB%B2%94%EC%9C%84-%EB%8B%A8%EC%9C%84%EB%A1%9C-repairing-%ED%95%98%EA%B8%B0를 참고한다.

***

나름 repair를 해보니..

compaction할 것이 없다면(즉 tombstone이 없다면), sstable이 많을 수록 오래걸리지만 많은 부하를 발생하지 않는다. sstable이 작더라도 키 개수가 많으면 오래 걸린다.

compaction할 것이 많다면(tombstone이 많으면), 키 개수와 상관없이 부하가 엄청 튄다.

79만개이지만 tombstone이 많으면 튄다... 하지만 6백만개의 키이지만 tombstone이 없으면 많이 튀지 않는다.

**

repair 실행할 때 키스페이스와 테이블을 설정할 수 있는데, 키스페이스 앞에 --을 두면 에러가 발생한다. -- 다음에 스페이스를 하나 두고 작업하는 것이 좋다.

$ nodetool repair --google_plus recent_relation

이건 에러가 발생한다.

$ nodetool repair -- google_plus recent_relation

성공

저작자표시

'cassandra' 카테고리의 다른 글

cassandra gc 튜닝 - compaction과 full gc (0)	2017.02.17
[cassandra] node subrange repair 작업 - 범위 단위로 repairing 하기 (0)	2017.01.31
[cassandra] 백업 - nodetool snapshot (0)	2017.01.31
cassandra table 변경 (0)	2017.01.26
[cassandra] repair 강제 종료하기 (0)	2017.01.26

Posted by '김용환'

,

[cassandra] 백업 - nodetool snapshot

cassandra 2017. 1. 31. 11:03

cassandra는 백업을 지원한다. cassandra에서는 snapshot이라고 부른다.

nodetool snapshot 커맨드를 사용해서 snapshot을 생성할 수 있다.

https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsSnapShot.html

$ nodetool snapshot -cf activity_history google

Requested creating snapshot(s) for [google] with snapshot name [1485312417477]

Snapshot directory: 1485312417477

정상적으로 저장되었는지 확인하려면 다음 커맨드를 실행한다. snapshot이라는 디렉토리가 생성되어 있다. ss

$ ls /data2/cassandra/data/google/activity_history-e37110b0b41c11e583234b983626f83b/snapshots/

1485312417477

해당 파일로 복구할 수 있다.

복구는 sstableloader를 사용한다.

http://docs.datastax.com/en/archived/cassandra/2.0/cassandra/tools/toolsBulkloader_t.html

저작자표시

'cassandra' 카테고리의 다른 글

[cassandra] node subrange repair 작업 - 범위 단위로 repairing 하기 (0)	2017.01.31
[cassandra] node repair 처리 방식 (0)	2017.01.31
cassandra table 변경 (0)	2017.01.26
[cassandra] repair 강제 종료하기 (0)	2017.01.26
cassandra repair 로그 정리 (0)	2017.01.26

Posted by '김용환'

,

cassandra table 변경

cassandra 2017. 1. 26. 13:17

TTL이 있고 삭제가 많은 카산드라 테이블에 대해서

너무 낮은 gc_grace_seconds는 read 성능을 떨어뜨리게 된다.

그렇다고 적당한 값으로 두기에는 언젠가는 compaction으로 cassandra가 gc로 인해 hang이 될 수 있다.

적당히 타협하기 위해 gc_grace_seconds의 기본값을 수정해 하루로 변경했다.

변경 방법은 cqlsh에 진행하며 다음 커맨드를 사용한다.

cqlsh:cluster_name> alter table google_plus.recent_relation with GC_GRACE_SECONDS = 86400;

확인은 다음과 같이 진행한다.

cqlsh:cluster_name> describe google_plus.recent_relation

좀 더 응용을 한다면, with 에 속성을 주면 테이블 속성을 변경할 수 있다.

참고로

alter 만 된다고 생각하는 분들이 있는데, 테이블 생성할 때부터 compaction 정책을 생성할 수 있다.

CREATE TABLE google_plus. recent_relation (

block_id uuid,

species text,

alias text,

population varint,

PRIMARY KEY (block_id)

) WITH compression =

{ 'sstable_compression' : 'DeflateCompressor', 'chunk_length_kb' : 64 }

AND compaction =

{ 'class' : 'LeveledCompactionStrategy'};

저작자표시

'cassandra' 카테고리의 다른 글

[cassandra] node repair 처리 방식 (0)	2017.01.31
[cassandra] 백업 - nodetool snapshot (0)	2017.01.31
[cassandra] repair 강제 종료하기 (0)	2017.01.26
cassandra repair 로그 정리 (0)	2017.01.26
[펌] cassandra summit 2016 자료 - 트러블 슈팅 (0)	2017.01.24

Posted by '김용환'

,

[cassandra] repair 강제 종료하기

cassandra 2017. 1. 26. 12:58

repair 종료하는 방법을 소개하고 있다.

https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsStop.html

$ nodetool stop -- COMPACTION

$ nodetool stop -- VALIDATION

jsoncole 등을 이용해 cassandra의 jmx로 접속한 후, org.apache.cassandra.db:type=StorageService를 실행한다.

jmx 프로그램을 이용해서 실행할 수 있다.

아래 url에서 jmx client 프로그램을 다운받을 수 있다.

https://sourceforge.net/projects/cyclops-group/files/jmxterm

$ wget -q -O jmxterm.jar http://downloads.sourceforge.net/cyclops-group/jmxterm-1.0-alpha-4-uber.jar

$ java -jar ./jmxterm.jar

$ open server-name:7199

$ bean org.apache.cassandra.db:type=StorageService

$ run forceTerminateAllRepairSessions

* 참고로.

cassandra의 repair 정책에 따라 다 끝낼 때까지 진행될 수도 있고,

특정 토큰에만 repair를 취소할 수 있다. (즉 다음 토큰으로 repair를 넘어가는 현상을 볼 수 있다)

계속 모니터링하면서 상황에 따라 유연하게 대처할 필요가 있다.

저작자표시

'cassandra' 카테고리의 다른 글

[cassandra] 백업 - nodetool snapshot (0)	2017.01.31
cassandra table 변경 (0)	2017.01.26
cassandra repair 로그 정리 (0)	2017.01.26
[펌] cassandra summit 2016 자료 - 트러블 슈팅 (0)	2017.01.24
[펌] cassandra summit 2016 중 compaction과 tombstone과 관련된 자료 (0)	2017.01.24

Posted by '김용환'

,

cassandra repair 로그 정리

cassandra 2017. 1. 26. 12:53

node repair를 실행할 때 관련 로그는 아래 url에서 설명하고 있다.

http://www.datastax.com/dev/blog/interpreting-repair-logs

실제로 nodetool repair를 실행하면 datastax url과 설명한 것과 비슷하게 나타난다. 공부하는데 도움될 것 같다.

1. RepairJob.java : merkle 트리 구성 요청을 보낸다.

2. RepairSession.java : merkle 트리 요청을 받는다.

3. Difference.java : 일치(consistency), 불일치(inconsistency)를 확인한다.

4. StreamingRepairTask.java : repair 스트림 상태를 알린다.

5. RepairSession.java : 싱크가 완료됨을 알린다.

6. StorageService.java : (발견하지 못했지만) repair 세션 범위를 알린다

아래는 실제 로그이다. 약간 차이가 나지만 큰 차이는 없다.

$ nodetool repair -- google_plus media

...

INFO [RepairJobTask:3] 2020-12-31 14:25:30,934 RepairJob.java:163 - [repair #b033fec0-e2be-11e6-bcf3-edb4e9adcd85] requesting merkle trees for media (to [/1.1.1.1, /1.1.1.2, /1.1.1.3])

INFO [AntiEntropyStage:1] 2020-12-31 14:25:30,939 RepairSession.java:171 - [repair #b033fec0-e2be-11e6-bcf3-edb4e9adcd85] Received merkle tree for media from /1.1.1.1

INFO [AntiEntropyStage:1] 2020-12-31 14:25:30,944 RepairSession.java:171 - [repair #b033fec0-e2be-11e6-bcf3-edb4e9adcd85] Received merkle tree for media from /1.1.1.2

INFO [AntiEntropyStage:1] 2020-12-31 14:25:30,949 RepairSession.java:171 - [repair #b033fec0-e2be-11e6-bcf3-edb4e9adcd85] Received merkle tree for media from /1.1.1.3

INFO [RepairJobTask:2] 2020-12-31 14:25:30,949 Differencer.java:67 - [repair #b033fec0-e2be-11e6-bcf3-edb4e9adcd85] Endpoints /1.1.1.1 and /1.1.1.3 are consistent for media

INFO [RepairJobTask:1] 2020-12-31 14:25:30,949 Differencer.java:67 - [repair #b033fec0-e2be-11e6-bcf3-edb4e9adcd85] Endpoints /1.1.1.2 and /1.1.1.3 are consistent for media

INFO [RepairJobTask:3] 2020-12-31 14:25:30,949 Differencer.java:67 - [repair #b033fec0-e2be-11e6-bcf3-edb4e9adcd85] Endpoints /1.1.1.1 and /1.1.1.2 are consistent for media

INFO [AntiEntropySessions:18] 2020-12-31 14:25:30,949 RepairSession.java:260 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] new session: will sync /1.1.1.3, /1.1.1.4, /1.1.1.5 on range (-7269152197870639307,-7265094729233520360] for google_plus.[media]

INFO [AntiEntropyStage:1] 2020-12-31 14:25:30,949 RepairSession.java:237 - [repair #b033fec0-e2be-11e6-bcf3-edb4e9adcd85] media is fully synced

INFO [AntiEntropySessions:20] 2020-12-31 14:25:30,949 RepairSession.java:299 - [repair #b033fec0-e2be-11e6-bcf3-edb4e9adcd85] session completed successfully

INFO [RepairJobTask:2] 2020-12-31 14:25:30,960 RepairJob.java:163 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] requesting merkle trees for media (to [/1.1.1.4, /1.1.1.5, /1.1.1.3])

INFO [AntiEntropyStage:1] 2020-12-31 14:25:30,961 RepairSession.java:171 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] Received merkle tree for media from /1.1.1.4

INFO [AntiEntropyStage:1] 2020-12-31 14:25:30,962 RepairSession.java:171 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] Received merkle tree for media from /1.1.1.5

INFO [AntiEntropyStage:1] 2020-12-31 14:25:30,963 RepairSession.java:171 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] Received merkle tree for media from /1.1.1.3

INFO [RepairJobTask:2] 2020-12-31 14:25:30,963 Differencer.java:67 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] Endpoints /1.1.1.4 and /1.1.1.5 are consistent for media

INFO [RepairJobTask:1] 2020-12-31 14:25:30,963 Differencer.java:67 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] Endpoints /1.1.1.4 and /1.1.1.3 are consistent for media

INFO [RepairJobTask:3] 2020-12-31 14:25:30,963 Differencer.java:67 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] Endpoints /1.1.1.5 and /1.1.1.3 are consistent for media

INFO [AntiEntropySessions:20] 2020-12-31 14:25:30,963 RepairSession.java:260 - [repair #b039f230-e2be-11e6-bcf3-edb4e9adcd85] new session: will sync /1.1.1.3, /1.1.1.1, /1.1.1.2 on range (4489624031702179489,4492484221112590824] for google_plus.[media]

INFO [AntiEntropyStage:1] 2020-12-31 14:25:30,963 RepairSession.java:237 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] media is fully synced

INFO [AntiEntropySessions:18] 2020-12-31 14:25:30,963 RepairSession.java:299 - [repair #b037cf50-e2be-11e6-bcf3-edb4e9adcd85] session completed successfully

....

INFO [RepairJobTask:2] 2020-12-31 14:31:28,036 RepairJob.java:163 - [repair #850e32f0-e2bf-11e6-bcf3-edb4e9adcd85] requesting merkle trees for media (to [/1.1.1.4, /1.1.1.7, /1.1.1.3])

INFO [AntiEntropyStage:1] 2020-12-31 14:31:28,106 RepairSession.java:171 - [repair #850e32f0-e2bf-11e6-bcf3-edb4e9adcd85] Received merkle tree for media from /1.1.1.4

INFO [AntiEntropyStage:1] 2020-12-31 14:31:28,177 RepairSession.java:171 - [repair #850e32f0-e2bf-11e6-bcf3-edb4e9adcd85] Received merkle tree for media from /1.1.1.7

INFO [AntiEntropyStage:1] 2020-12-31 14:31:28,221 RepairSession.java:171 - [repair #850e32f0-e2bf-11e6-bcf3-edb4e9adcd85] Received merkle tree for media from /1.1.1.3

INFO [RepairJobTask:2] 2020-12-31 14:31:28,221 Differencer.java:74 - [repair #850e32f0-e2bf-11e6-bcf3-edb4e9adcd85] Endpoints /1.1.1.4 and /1.1.1.7 have 2 range(s) out of sync for media

INFO [RepairJobTask:3] 2020-12-31 14:31:28,221 Differencer.java:67 - [repair #850e32f0-e2bf-11e6-bcf3-edb4e9adcd85] Endpoints /1.1.1.7 and /1.1.1.3 are consistent for media

INFO [RepairJobTask:1] 2020-12-31 14:31:28,221 Differencer.java:74 - [repair #850e32f0-e2bf-11e6-bcf3-edb4e9adcd85] Endpoints /1.1.1.4 and /1.1.1.3 have 2 range(s) out of sync for media

INFO [RepairJobTask:2] 2020-12-31 14:31:28,221 StreamingRepairTask.java:81 - [repair #850e32f0-e2bf-11e6-bcf3-edb4e9adcd85] Forwarding streaming repair of 2 ranges to /1.1.1.4 (to be streamed with /1.1.1.7)

INFO [RepairJobTask:1] 2020-12-31 14:31:28,223 StreamingRepairTask.java:68 - [streaming task #850e32f0-e2bf-11e6-bcf3-edb4e9adcd85] Performing streaming repair of 2 ranges with /1.1.1.4

INFO [RepairJobTask:1] 2020-12-31 14:31:28,224 ColumnFamilyStore.java:912 - Enqueuing flush of media: 364 (0%) on-heap, 80 (0%) off-heap

INFO [MemtableFlushWriter:14683] 2020-12-31 14:31:28,224 Memtable.java:347 - Writing Memtable-media@1433910433(0.033KiB serialized bytes, 1 ops, 0%/0% of on/off-heap limit)

INFO [MemtableFlushWriter:14683] 2020-12-31 14:31:28,224 Memtable.java:382 - Completed flushing /var/lib/cassandra/data/google_plus/media-6c2e8460af9311e69f844b983626f83b/google_plus-media-tmp-ka-2204-Data.db (0.000KiB) for commitlog position ReplayPosition(segmentId=1483928411656, position=2911640)

INFO [MemtableFlushWriter:14683] 2020-12-31 14:31:28,228 Memtable.java:347 - Writing Memtable-media.friend_profileid_index@1788192341(0.030KiB serialized bytes, 1 ops, 0%/0% of on/off-heap limit)

INFO [MemtableFlushWriter:14683] 2020-12-31 14:31:28,228 Memtable.java:382 - Completed flushing /var/lib/cassandra/data/google_plus/media-6c2e8460af9311e69f844b983626f83b/google_plus-media.friend_profileid_index-tmp-ka-1997-Data.db (0.000KiB) for commitlog position ReplayPosition(segmentId=1483928411656, position=2911640)

INFO [RepairJobTask:1] 2020-12-31 14:31:28,232 StreamResultFuture.java:86 - [Stream #852b7ef0-e2bf-11e6-bcf3-edb4e9adcd85] Executing streaming plan for Repair

INFO [StreamConnectionEstablisher:12] 2020-12-31 14:31:28,232 StreamSession.java:220 - [Stream #852b7ef0-e2bf-11e6-bcf3-edb4e9adcd85] Starting streaming to /1.1.1.4

INFO [StreamConnectionEstablisher:12] 2020-12-31 14:31:28,233 StreamCoordinator.java:209 - [Stream #852b7ef0-e2bf-11e6-bcf3-edb4e9adcd85, ID#0] Beginning stream session with /1.1.1.4

INFO [STREAM-IN-/1.1.1.4] 2020-12-31 14:31:28,240 StreamResultFuture.java:166 - [Stream #852b7ef0-e2bf-11e6-bcf3-edb4e9adcd85 ID#0] Prepare completed. Receiving 2 files(80817 bytes), sending 1 files(80161 bytes)

INFO [StreamReceiveTask:543] 2020-12-31 14:31:28,248 SecondaryIndexManager.java:163 - Submitting index build of [media.friend_profileid_index] for data in SSTableReader(path='/var/lib/cassandra/data/google_plus/media-6c2e8460af9311e69f844b983626f83b/google_plus-media-ka-2205-Data.db'), SSTableReader(path='/var/lib/cassandra/data/google_plus/media-6c2e8460af9311e69f844b983626f83b/google_plus-media-ka-2206-Data.db')

문제가 있었는지 확인하기 위해 로그를 확인하는 방법이다.

$ grep -r 'Sync failed' /var/log/cassandra/system.log

..

$ grep -i -e "ERROR" -e "WARN" /var/log/cassandra/system.log

..

WARN [SharedPool-Worker-1] 2020-01-14 13:17:13,272 SliceQueryFilter.java:319 - Read 6 live and 1157 tombstone cells in google_plus.part_of_friend_permission_activities.allow_profile_ids_idx for key: 04727367 (see tombstone_warn_threshold). 200 columns were requested, slices=[04488138:_-04488138:!]

WARN [SharedPool-Worker-7] 2020-01-14 13:17:13,287 SliceQueryFilter.java:319 - Read 6 live and 1157 tombstone cells in google_plus.part_of_friend_permission_activities.allow_profile_ids_idx for key: 04727367 (see tombstone_warn_threshold). 200 columns were requested, slices=[04488138:_-04488138:!]

java.io.IOException: Error while read(...): 연결 시간 초과

WARN [SharedPool-Worker-3] 2020-01-17 10:58:03,992 SliceQueryFilter.java:319 - Read 7 live and 1330 tombstone cells in google_plus.part_of_friend_permission_activities.allow_profile_ids_idx for key: 04ee9da7 (see tombstone_warn_threshold). 200 columns were requested, slices=[04f4dfdb:_-04f4dfdb:!]

java.io.IOException: Error while read(...): 연결이 상대편에 의해 끊어짐

WARN [SharedPool-Worker-3] 2020-01-24 12:11:57,223 SliceQueryFilter.java:319 - Read 4 live and 1232 tombstone cells in google_plus.part_of_friend_permission_activities.allow_profile_ids_idx for key: 04e66181 (see tombstone_warn_threshold). 200 columns were requested, slices=[04f4dfdb:_-04f4dfdb:!]

WARN [SharedPool-Worker-4] 2017-01-24 12:11:57,289 SliceQueryFilter.java:319 - Read 4 live and 1232 tombstone cells in google_plus.part_of_friend_permission_activities.allow_profile_ids_idx for key: 04e66181 (see tombstone_warn_threshold). 21 columns were requested, slices=[04f4dfdb:_-04f4dfdb:!]

저작자표시

'cassandra' 카테고리의 다른 글

cassandra table 변경 (0)	2017.01.26
[cassandra] repair 강제 종료하기 (0)	2017.01.26
[펌] cassandra summit 2016 자료 - 트러블 슈팅 (0)	2017.01.24
[펌] cassandra summit 2016 중 compaction과 tombstone과 관련된 자료 (0)	2017.01.24
cassandra의 동기화를 유지하는 메커니즘 (0)	2017.01.19

Posted by '김용환'

,

[펌] cassandra summit 2016 자료 - 트러블 슈팅

cassandra 2017. 1. 24. 18:09

Troubleshooting Cassandra (J.B. Langston, DataStax) | C* Summit 2016 from DataStax

1

저작자표시

'cassandra' 카테고리의 다른 글

[cassandra] repair 강제 종료하기 (0)	2017.01.26
cassandra repair 로그 정리 (0)	2017.01.26
[펌] cassandra summit 2016 중 compaction과 tombstone과 관련된 자료 (0)	2017.01.24
cassandra의 동기화를 유지하는 메커니즘 (0)	2017.01.19
[cassandra] hinted_handoff_enabled (0)	2017.01.18

Posted by '김용환'

,

[펌] cassandra summit 2016 중 compaction과 tombstone과 관련된 자료

cassandra 2017. 1. 24. 18:05

cassandra summit 2016 중 compaction과 tombstone과 관련된 자료

Deletes Without Tombstones or TTLs (Eric Stevens, ProtectWise) | Cassandra Summit 2016 from DataStax

Cassandra at Instagram 2016 (Dikang Gu, Facebook) | Cassandra Summit 2016 from DataStax

How Cassandra Deletes Data (Alain Rodriguez, The Last Pickle) | Cassandra Summit 2016 from DataStax

저작자표시

'cassandra' 카테고리의 다른 글

cassandra repair 로그 정리 (0)	2017.01.26
[펌] cassandra summit 2016 자료 - 트러블 슈팅 (0)	2017.01.24
cassandra의 동기화를 유지하는 메커니즘 (0)	2017.01.19
[cassandra] hinted_handoff_enabled (0)	2017.01.18
[cassandra] 카산드라 팁 - 조심히 사용해야 할 내용 (0)	2017.01.17

Posted by '김용환'

,

'cassandra'에 해당되는 글 54건

[cassandra] 클라이언트 라이브러리 하위 호환성 지원 (cassandra java driver compatibility)

Native protocol

Compatibility matrix

'cassandra' 카테고리의 다른 글

cassandra gc 튜닝 - compaction과 full gc

'cassandra' 카테고리의 다른 글

[cassandra] node subrange repair 작업 - 범위 단위로 repairing 하기

'cassandra' 카테고리의 다른 글

[cassandra] node repair 처리 방식

'cassandra' 카테고리의 다른 글

[cassandra] 백업 - nodetool snapshot

'cassandra' 카테고리의 다른 글

cassandra table 변경

'cassandra' 카테고리의 다른 글

[cassandra] repair 강제 종료하기

'cassandra' 카테고리의 다른 글

cassandra repair 로그 정리

'cassandra' 카테고리의 다른 글

[펌] cassandra summit 2016 자료 - 트러블 슈팅

'cassandra' 카테고리의 다른 글

[펌] cassandra summit 2016 중 compaction과 tombstone과 관련된 자료

'cassandra' 카테고리의 다른 글

카테고리

태그목록

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

글 보관함

달력

링크

티스토리툴바