Return-Path: X-Original-To: apmail-cassandra-commits-archive@www.apache.org Delivered-To: apmail-cassandra-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1DB1F10282 for ; Fri, 14 Mar 2014 09:15:48 +0000 (UTC) Received: (qmail 97389 invoked by uid 500); 14 Mar 2014 09:15:47 -0000 Delivered-To: apmail-cassandra-commits-archive@cassandra.apache.org Received: (qmail 97205 invoked by uid 500); 14 Mar 2014 09:15:46 -0000 Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list commits@cassandra.apache.org Received: (qmail 97163 invoked by uid 99); 14 Mar 2014 09:15:44 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Mar 2014 09:15:44 +0000 Date: Fri, 14 Mar 2014 09:15:44 +0000 (UTC) From: "Duncan Sands (JIRA)" To: commits@cassandra.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CASSANDRA-6799) schema_version of newly bootstrapped nodes disagrees with existing nodes MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CASSANDRA-6799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13934802#comment-13934802 ] Duncan Sands commented on CASSANDRA-6799: ----------------------------------------- Something I noticed while working with 2.0.5 (I'm now on 2.0.6 but didn't make any schema changes yet) is that dropping a table resulted in schema version disagreements all over the cluster, i.e. before dropping the table all nodes agreed on the schema version, after dropping the table this was no longer the case. Restarting all nodes fixed this. On the other hand, adding tables didn't cause any trouble: all nodes immediately moved to the same new schema version. Maybe it was due to CASSANDRA-6700, in which case 2.0.6 should be OK. > schema_version of newly bootstrapped nodes disagrees with existing nodes > ------------------------------------------------------------------------ > > Key: CASSANDRA-6799 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6799 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: x86_64 ubuntu, java version "1.7.0_45", Cassandra 2.0.5 > Reporter: Duncan Sands > Attachments: system.log.gz > > > After bootstrapping new nodes 172.18.33.23 and 172.18.33.24 last weekend, I noticed that they have a different schema_version to the existing nodes. The existing nodes have all been around for a while, saw some schema changes in the past (eg: timeuuid -> timestamp on a column family) but none recently, and were originally running 1.2 (they were upgraded to 2.0.5). Here you see the different schema version 0d9173d5-3947-328e-a14d-ce05239f61e0 for the two nodes: > cqlsh> select peer, data_center, host_id, preferred_ip, rack, release_version, rpc_address, schema_version from system.peers; > peer | data_center | host_id | preferred_ip | rack | release_version | rpc_address | schema_version > ----------------+-------------+--------------------------------------+--------------+------+-----------------+----------------+-------------------------------------- > 192.168.21.12 | rdm | 55e4b4b6-2e64-4542-87a4-d8a8e28b5135 | null | RAC1 | 2.0.5 | 192.168.21.12 | f673ced0-8cfd-3d69-baba-4f81dc60c5b5 > 172.18.33.24 | ldn | 6e634206-94b6-4dcf-9cf8-72bfe190feee | null | RAC1 | 2.0.5 | 172.18.33.24 | 0d9173d5-3947-328e-a14d-ce05239f61e0 > 172.18.33.22 | ldn | 75c9c81f-b00b-4335-8483-fb7f1bc0be1e | null | RAC1 | 2.0.5 | 172.18.33.22 | f673ced0-8cfd-3d69-baba-4f81dc60c5b5 > 192.168.60.136 | adm | c83d403f-ef0d-4c54-a844-d69730fa54d3 | null | RAC1 | 2.0.5 | 192.168.60.136 | f673ced0-8cfd-3d69-baba-4f81dc60c5b5 > 192.168.60.137 | adm | b12e6d71-e189-4fe8-b00a-8ff2cc9848fd | null | RAC1 | 2.0.5 | 192.168.60.137 | f673ced0-8cfd-3d69-baba-4f81dc60c5b5 > 192.168.21.11 | rdm | dd2e69cb-232f-4236-89f2-b5479669d9f7 | null | RAC1 | 2.0.5 | 192.168.21.11 | f673ced0-8cfd-3d69-baba-4f81dc60c5b5 > 172.18.33.21 | ldn | 6942404c-e512-46b4-977a-243defa48d0f | null | RAC1 | 2.0.5 | 172.18.33.21 | f673ced0-8cfd-3d69-baba-4f81dc60c5b5 > 192.168.60.138 | adm | a229bc0f-201b-479e-8312-66891f37ca85 | null | RAC1 | 2.0.5 | 192.168.60.138 | f673ced0-8cfd-3d69-baba-4f81dc60c5b5 > 192.168.60.134 | adm | 7b860a54-59ea-4a92-9b47-44b52793cc70 | null | RAC1 | 2.0.5 | 192.168.60.134 | f673ced0-8cfd-3d69-baba-4f81dc60c5b5 > 172.18.33.23 | ldn | a08bad62-55bb-492b-be64-7cf5d5073d6d | null | RAC1 | 2.0.5 | 172.18.33.23 | 0d9173d5-3947-328e-a14d-ce05239f61e0 > 192.168.60.130 | adm | 3498b4b8-1047-4b42-b13b-bf27b3aa3177 | null | RAC1 | 2.0.5 | 192.168.60.130 | f673ced0-8cfd-3d69-baba-4f81dc60c5b5 > 192.168.60.133 | adm | 21d3faad-5c5d-447e-bab4-ad9323bdf4c1 | null | RAC1 | 2.0.5 | 192.168.60.133 | f673ced0-8cfd-3d69-baba-4f81dc60c5b5 > 192.168.60.135 | adm | 860ff4bb-4fcf-43ba-b270-f1844bdd3e65 | null | RAC1 | 2.0.5 | 192.168.60.135 | f673ced0-8cfd-3d69-baba-4f81dc60c5b5 > 192.168.60.131 | adm | d8b7b0b2-d697-43ae-ad6e-982b24637865 | null | RAC1 | 2.0.5 | 192.168.60.131 | f673ced0-8cfd-3d69-baba-4f81dc60c5b5 > (14 rows) > I've attached the Cassandra log showing the 172.18.33.23 node bootstrapping. -- This message was sent by Atlassian JIRA (v6.2#6252)