Tạo bảng mới với cqlsh trên không gian phím hiện có: Cột ID gia đình không khớp

Question

Houston, chúng tôi gặp sự cố.

Đang cố gắng để tạo ra một bảng mới với cqlsh trên một kết quả Cassandra (v2.1.3) keyspace hiện tại:

ServerError: 
<ErrorMessage code=0000 [Server error] message="java.lang.RuntimeException: 
java.util.concurrent.ExecutionException: 
    java.lang.RuntimeException:  
     org.apache.cassandra.exceptions.ConfigurationException: Column family ID mismatch (found e8c03790-c952-11e4-a753-5981ea73cd7c; expected e8b14370-c952-11e4-a844-8f10bfb9c386)"> 

Sau khi nỗ lực đầu tiên tạo ra, cố gắng một lần nữa sẽ cho kết quả:

AlreadyExists : Bảng 'ks.metrics' đã tồn tại

Nhưng việc truy xuất danh sách các bảng hiện có cho không gian phím desc tables; sẽ không báo cáo bảng mới.

Vấn đề này dường như liên quan đến Cassandra-8387 ngoại trừ việc chỉ có một khách hàng cố gắng để tạo ra bảng: cqlsh

Chúng tôi có một loạt các công việc Spark rằng sẽ tạo ra keyspaces và bảng lúc khởi động, có khả năng làm điều này song song . Điều này sẽ làm cho không gian phím bị hỏng?

Tạo không gian phím mới và thêm bảng vào nó hoạt động như mong đợi.

Bất kỳ ý tưởng nào?

CẬP NHẬT

Tìm thấy một workaround: hành sửa chữa trên keyspace và các bảng sẽ xuất hiện (desc tables) và cũng có chức năng.

Answer 1

Câu trả lời ngắn:They have a race condition, mà họ nghĩ rằng họ giải quyết trong 1.1.8 ...

---

Long trả lời:

tôi nhận được rằng lỗi tất cả các thời gian trên một các cụm của tôi. Tôi có máy thử nghiệm có ổ đĩa cứng thực sự chậm và tạo ra một hoặc hai bảng là đủ để có được lỗi khi tôi có 4 nút trên hai máy tính riêng biệt.

Dưới đây tôi có một bản sao của dấu vết ngăn xếp từ cài đặt Cassandra 3.7 của tôi. Mặc dù phiên bản của bạn là 2.1.3, tôi sẽ ngạc nhiên rằng phần mã này đã thay đổi rất nhiều.

Như chúng ta có thể thấy, ngoại lệ xảy ra ở hàm validateCompatibility(). Điều này đòi hỏi các phiên bản mới và cũ của MetaData có những bằng:

• ksName (tên keyspace)
• cfName (tên columnfamily)
• cfId (columnfamily UUID)
• cờ (isSuper, isCounter , isDense, isCompound)
• so sánh (key sắp xếp so sánh)

Nếu bất kỳ một trong những giá trị không phù hợp giữa cái cũ và mới Mê dữ liệu của chúng tôi, sau đó quá trình này đưa ra một ngoại lệ.Trong trường hợp của chúng tôi, các giá trị cfId khác nhau.

Đi lên ngăn xếp, chúng tôi có số apply() gọi ngay validateCompatibility().

Tiếp theo, chúng tôi có updateTable(). Tương tự, nó gọi apply() gần như ngay lập tức. Đầu tiên nó gọi số getCFMetaData() để lấy dữ liệu gia đình cột hiện tại ("cũ") sẽ được so sánh với dữ liệu mới.

Tiếp theo, chúng tôi thấy updateKeyspace(). Chức năng đó tính toán diff để biết điều gì đã thay đổi. Sau đó, nó tiết kiệm rằng trong mỗi loại dữ liệu. Bảng là thứ hai sau khi nhập ...

Trước đó, chúng có mergeSchema() để tính toán những gì đã thay đổi ở mức Keyspace. Sau đó, nó sẽ loại bỏ các không gian bị xóa và tạo ra các không gian mới cho những không gian đã được cập nhật (và cho các không gian chính mới). Cuối cùng, họ lặp qua các không gian phím mới gọi updateKeyspace() cho mỗi một trong số chúng.

Tiếp theo trong ngăn xếp, chúng ta sẽ thấy một chức năng thú vị: mergeSchemaAndAnnounceVersion(). Điều này sẽ cập nhật phiên bản khi các không gian phím được cập nhật trong bộ nhớ và trên đĩa. Phiên bản của lược đồ bao gồm cfID không tương thích và do đó tạo ra ngoại lệ. Phần Announce là gửi một tin nhắn gossip đến các nút khác về thực tế là nút này bây giờ biết về phiên bản mới của một lược đồ nhất định.

Tiếp theo, chúng ta sẽ thấy thứ gọi là MigrationTask. Đây là thông điệp được sử dụng để di chuyển các thay đổi giữa các nút Cassandra. Tải trọng tin nhắn là một tập hợp các đột biến (các chức năng được xử lý bởi hàm mergeSchema().)

Phần còn lại của ngăn xếp chỉ hiển thị các chức năng được sử dụng để xử lý tin nhắn.

Trong trường hợp của tôi, đối với tôi sự cố được giải quyết sau một chút và tất cả đều tốt. Tôi không có gì để làm cho lược đồ để cuối cùng có được đồng bộ. như mong đợi. Tuy nhiên, nó ngăn cản tôi tạo ra tất cả các bảng của tôi trong một lần. Vì vậy, tôi xem xét điều này là các tin nhắn di chuyển không đến theo thứ tự mong đợi. Phải có một thời gian chờ được xử lý bằng cách gửi lại sự kiện và tạo ra sự kết hợp.

Vì vậy, hãy xem mã gửi thư ngay từ đầu, bạn sẽ thấy thông báo đó trong Trình quản lý di chuyển. Ở đây chúng tôi có thông số MIGRATION_DELAY_IN_MS liên kết với sự cố cũ, Schema push/pull race, để tránh tình trạng chạy đua. Vâng ... có bạn đi. Vì vậy, họ nhận thức được rằng có một điều kiện chủng tộc có thể và để tránh nó, họ đã thêm một chút chậm trễ ở đó. Một phần của bản sửa lỗi đó bao gồm kiểm tra phiên bản. Nếu các phiên bản đã bằng nhau, hãy tránh hoàn toàn cập nhật (tức là bỏ qua tin đồn đó).

if (Schema.instance.getVersion().equals(currentVersion)) 
{ 
    logger.debug("not submitting migration task for {} because our versions match", endpoint); 
    return; 
} 

Việc chậm trễ chúng ta đang nói về là một phút:

public static final int MIGRATION_DELAY_IN_MS = 60000; 

Một sẽ nghĩ rằng toàn bộ một phút là đã đủ, nhưng bằng cách nào đó tôi vẫn nhận được lỗi tất cả các thời gian.

Thực tế là mã của họ không mong đợi nhiều thay đổi xảy ra một sau khi khác bao gồm cả sự chậm trễ lớn như tôi có. Vì vậy, nếu tôi đã tạo ra một bảng, và sau đó làm những việc khác, tôi sẽ được tốt. Mặt khác, khi tôi muốn tạo 20 bảng liên tiếp trên các máy chậm đó, thông báo tin đồn từ một thay đổi lược đồ trước đến muộn (tức là sau khi lệnh CREATE TABLE mới đến nút đó.) Đó là khi tôi nhận được lỗi đó .Phần tồi tệ nhất, tôi đoán, là nó là một lỗi giả mạo (tức là nó nói với tôi rằng tin đồn là sau đó, và không phải là lược đồ của tôi là không hợp lệ và lược đồ trong tin nhắn gossip là cũ.)

org.apache.cassandra.exceptions.ConfigurationException: Column family ID mismatch (found 122a2d20-9e13-11e6-b830-55bace508971; expected 1213bef0-9e 
    at org.apache.cassandra.config.CFMetaData.validateCompatibility(CFMetaData.java:790) ~[apache-cassandra-3.9.jar:3.9] 
    at org.apache.cassandra.config.CFMetaData.apply(CFMetaData.java:750) ~[apache-cassandra-3.9.jar:3.9] 
    at org.apache.cassandra.config.Schema.updateTable(Schema.java:661) ~[apache-cassandra-3.9.jar:3.9] 
    at org.apache.cassandra.schema.SchemaKeyspace.updateKeyspace(SchemaKeyspace.java:1350) ~[apache-cassandra-3.9.jar:3.9] 
    at org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1306) ~[apache-cassandra-3.9.jar:3.9] 
    at org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1256) ~[apache-cassandra-3.9.jar:3.9] 
    at org.apache.cassandra.service.MigrationTask$1.response(MigrationTask.java:92) ~[apache-cassandra-3.9.jar:3.9] 
    at org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:53) [apache-cassandra-3.9.jar:3.9] 
    at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) [apache-cassandra-3.9.jar:3.9] 
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_111] 
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_111] 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_111] 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_111] 
    at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111] 

Answer 2

Tôi đã có hai lược đồ bảng khác nhau với cùng một tên bảng do nhầm lẫn. do đó, vấn đề này đã xảy ra (tôi đang sử dụng express-cassandra)