Несбалансированное использование диска среди узлов в CouchDB

Question

Я создал кластер CouchDB из 4 узлов для хранения полученных твитов.

Кластер был настроен на 8 сегментов и 3 копии каждого документа.

[cluster]
q=8
r=2
w=2
n=3

Я не добавил ни одного представления или дополнительных индексов, и размер базы данных, показанной в Fauxton, равен 4.3 GB

Однако CouchDB занимает исключительно большое дисковое пространство в одном из узлов

$ ansible -i hosts -s -m shell -a 'du /vol/couchdb/shards/* -sh' couchdb
crake.couchdb.cloud | SUCCESS | rc=0 >>
363M    /vol/couchdb/shards/00000000-1fffffff
990M    /vol/couchdb/shards/20000000-3fffffff
17G     /vol/couchdb/shards/40000000-5fffffff
1.4G    /vol/couchdb/shards/60000000-7fffffff
359M    /vol/couchdb/shards/80000000-9fffffff
989M    /vol/couchdb/shards/a0000000-bfffffff
12G     /vol/couchdb/shards/c0000000-dfffffff
1.6G    /vol/couchdb/shards/e0000000-ffffffff

darter.couchdb.cloud | SUCCESS | rc=0 >>
1.4G    /vol/couchdb/shards/00000000-1fffffff
367M    /vol/couchdb/shards/20000000-3fffffff
1001M   /vol/couchdb/shards/40000000-5fffffff
1.4G    /vol/couchdb/shards/60000000-7fffffff
1.4G    /vol/couchdb/shards/80000000-9fffffff
364M    /vol/couchdb/shards/a0000000-bfffffff
998M    /vol/couchdb/shards/c0000000-dfffffff
1.4G    /vol/couchdb/shards/e0000000-ffffffff

bustard.couchdb.cloud | SUCCESS | rc=0 >>
1004M   /vol/couchdb/shards/00000000-1fffffff
1.4G    /vol/couchdb/shards/20000000-3fffffff
1.4G    /vol/couchdb/shards/40000000-5fffffff
365M    /vol/couchdb/shards/60000000-7fffffff
1001M   /vol/couchdb/shards/80000000-9fffffff
1.4G    /vol/couchdb/shards/a0000000-bfffffff
1.4G    /vol/couchdb/shards/c0000000-dfffffff
364M    /vol/couchdb/shards/e0000000-ffffffff

avocet.couchdb.cloud | SUCCESS | rc=0 >>
1.4G    /vol/couchdb/shards/00000000-1fffffff
1.4G    /vol/couchdb/shards/20000000-3fffffff
368M    /vol/couchdb/shards/40000000-5fffffff
999M    /vol/couchdb/shards/60000000-7fffffff
1.4G    /vol/couchdb/shards/80000000-9fffffff
1.4G    /vol/couchdb/shards/a0000000-bfffffff
364M    /vol/couchdb/shards/c0000000-dfffffff
1001M   /vol/couchdb/shards/e0000000-ffffffff

В crake.couchdb.cloudдва осколка, 40000000-5fffffff а также c0000000-dfffffff, гораздо больше, чем другие.

Однажды я попытался удалить эти большие осколки в crake.couchdb.cloud и ждал сам CouchDB, чтобы восстановить. После перестроения использование диска было сбалансированным, однако после того, как я начал добавлять новые документы в базу данных, он снова стал несбалансированным.

я использую MD5(tweet[id_str]) в качестве идентификатора документа. Может ли это быть причиной проблемы?

Я действительно смущен этим, так как думаю, что даже если бы я допустил какие-либо ошибки, это должно было бы израсходовать ресурсы 3 разных узлов, поскольку данные реплицируются по всему кластеру.

Пожалуйста, помогите, спасибо.

ОБНОВИТЬ

Позже я удалил все экземпляры VPS и перестроил кластер с 3 узлами CouchDB, а именно Avocet, Bustard а также Crake, Новая конфигурация кластера выглядит следующим образом:

[cluster]
q=12
r=2
w=2
n=2

Перед перестройкой я реплицировал все данные в альтернативный экземпляр CouchDB, чтобы я мог перенести их обратно после завершения. Использование диска было сбалансировано после восстановления.

Кроме того, я ввел HAProxy на 4-м узле, а именно Darter, как балансировщик нагрузки.

Так что на этот раз все мои твиттер-ретрансляторы отправляют свои запросы на балансировщик. Однако использование диска снова стало несбалансированным, и это был именно 3-й узел Crake который занял гораздо больше места.

bustard.couchdb.cloud | SUCCESS | rc=0 >>
Filesystem      Size  Used Avail Use% Mounted on
/dev/vdc         81G  9.4G   68G  13% /vol

avocet.couchdb.cloud | SUCCESS | rc=0 >>
Filesystem      Size  Used Avail Use% Mounted on
/dev/vdc         81G  9.3G   68G  13% /vol

crake.couchdb.cloud | SUCCESS | rc=0 >>
Filesystem      Size  Used Avail Use% Mounted on
/dev/vdc         81G   30G   48G  39% /vol

Размер базы данных только 4.2 GB а также Crake примерно в 7 раз больше!

Я сейчас совершенно не в курсе...

ОБНОВЛЕНИЕ 2

_dbs информация со всех узлов

crake.couchdb.cloud | SUCCESS | rc=0 >>
{
    "db_name": "_dbs",
    "update_seq": "11-g2wAAAABaANkABtjb3VjaGRiQGNyYWtlLmNvdWNoZGIuY2xvdWRsAAAAAmEAbgQA_____2phC2o",
    "sizes": {
        "file": 131281,
        "external": 8313,
        "active": 9975
    },
    "purge_seq": 0,
    "other": {
        "data_size": 8313
    },
    "doc_del_count": 0,
    "doc_count": 7,
    "disk_size": 131281,
    "disk_format_version": 6,
    "data_size": 9975,
    "compact_running": false,
    "instance_start_time": "0"
}

avocet.couchdb.cloud | SUCCESS | rc=0 >>
{
    "db_name": "_dbs",
    "update_seq": "15-g2wAAAABaANkABxjb3VjaGRiQGF2b2NldC5jb3VjaGRiLmNsb3VkbAAAAAJhAG4EAP____9qYQ9q",
    "sizes": {
        "file": 159954,
        "external": 8313,
        "active": 10444
    },
    "purge_seq": 0,
    "other": {
        "data_size": 8313
    },
    "doc_del_count": 0,
    "doc_count": 7,
    "disk_size": 159954,
    "disk_format_version": 6,
    "data_size": 10444,
    "compact_running": false,
    "instance_start_time": "0"
}

bustard.couchdb.cloud | SUCCESS | rc=0 >>
{
    "db_name": "_dbs",
    "update_seq": "15-g2wAAAABaANkAB1jb3VjaGRiQGJ1c3RhcmQuY291Y2hkYi5jbG91ZGwAAAACYQBuBAD_____amEPag",
    "sizes": {
        "file": 159955,
        "external": 8313,
        "active": 9999
    },
    "purge_seq": 0,
    "other": {
        "data_size": 8313
    },
    "doc_del_count": 0,
    "doc_count": 7,
    "disk_size": 159955,
    "disk_format_version": 6,
    "data_size": 9999,
    "compact_running": false,
    "instance_start_time": "0"
}