Saya memiliki cluster ES dengan 4 node:
number_of_replicas: 1
search01 - master: false, data: false
search02 - master: true, data: true
search03 - master: false, data: true
search04 - master: false, data: true
Saya harus me-restart search03, dan ketika kembali, itu bergabung kembali dengan cluster tidak ada masalah, tetapi meninggalkan 7 pecahan yang tidak ditugaskan meletakkan tentang.
{
"cluster_name" : "tweedle",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 4,
"number_of_data_nodes" : 3,
"active_primary_shards" : 15,
"active_shards" : 23,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 7
}
Sekarang kluster saya dalam kondisi kuning. Apa cara terbaik untuk mengatasi masalah ini?
- Hapus (batalkan) pecahan?
- Pindahkan pecahan ke simpul lain?
- Mengalokasikan pecahan ke node?
- Perbarui 'number_of_replicas' ke 2?
- Sesuatu yang lain sama sekali?
Menariknya, ketika indeks baru ditambahkan, simpul itu mulai bekerja di sana dan bermain bagus dengan seluruh cluster, itu hanya meninggalkan pecahan yang belum ditetapkan meletakkan.
Ikuti pertanyaan: apakah saya melakukan sesuatu yang salah yang menyebabkan hal ini terjadi? Saya tidak memiliki banyak kepercayaan pada gugus yang berperilaku seperti ini ketika sebuah simpul dimulai kembali.
CATATAN: Jika Anda menjalankan satu cluster node untuk beberapa alasan, Anda mungkin perlu melakukan hal berikut:
curl -XPUT 'localhost:9200/_settings' -d '
{
"index" : {
"number_of_replicas" : 0
}
}'
sumber
{ "error" : "ElasticsearchIllegalArgumentException[[allocate] failed to find [logstash-2015.01.05][1] on the list of unassigned shards]", "status" : 400 }
Meskipun saya dapat melihat bahwa beling adalah salah satu yang tidak terisi di ES-Head-H 'Content-Type: application/json'
jika Anda mendapatkan kesalahanContent-Type header [application/x-www-form-urlencoded] is not supported
OK, saya sudah menyelesaikan ini dengan bantuan dari dukungan ES. Keluarkan perintah berikut untuk API pada semua node (atau node yang Anda yakini sebagai penyebab masalah):
di mana
<index>
indeks yang Anda yakini sebagai pelakunya? Jika Anda tidak tahu, jalankan ini di semua node:Saya juga menambahkan baris ini ke konfigurasi yaml saya dan sejak itu, setiap restart dari server / layanan telah bebas masalah. Pecahan dialokasikan kembali segera.
FWIW, untuk menjawab pertanyaan yang sering dicari, setel MAX_HEAP_SIZE ke 30G kecuali mesin Anda memiliki kurang dari 60G RAM, dalam hal ini setel ke setengah dari memori yang tersedia.
Referensi
sumber
index.routing.allocation.disable_allocation : false cluster.routing.allocation.enable: none
Tapi masih ada pecahan yang belum ditetapkan menunjukkan .. Apa yang bisa menjadi alasannya?{ "type": "illegal_argument_exception", "reason": "unknown setting [index.routing.allocation.disable_allocation] please check that any required plugins are installed, or check the breaking changes documentation for removed settings" } ],
Skrip bash kecil ini akan mengubah tugas dengan paksa, Anda mungkin kehilangan data.
sumber
{"error":"Content-Type header [application/x-www-form-urlencoded] is not supported","status":406}{"error":"Content-Type header [application/x-www-form-urlencoded] is not supported","status":406}
Satu-satunya hal yang berhasil bagi saya adalah mengubah number_of_replicas (saya punya 2 replika, jadi saya mengubahnya menjadi 1 dan kemudian kembali ke 2).
Pertama:
Kemudian:
(Saya sudah menjawabnya dalam pertanyaan ini )
sumber
Elasticsearch secara otomatis mengalokasikan pecahan jika konfigurasi di bawah ini diatur ke semua. Konfigurasi ini dapat diatur menggunakan api sisanya juga cluster.routing.allocation.enable: all
Jika bahkan setelah penerapan konfigurasi di bawah ini, es gagal menetapkan pecahan secara otomatis, maka Anda harus memaksa menetapkan pecahan sendiri. Tautan resmi ES untuk ini
Saya telah menulis sebuah skrip untuk memaksa menetapkan semua pecahan yang belum ditetapkan di seluruh cluster.
array di bawah ini berisi daftar node di mana Anda ingin menyeimbangkan pecahan yang belum ditetapkan
sumber
Saya terjebak hari ini dengan masalah alokasi pecahan yang sama. Skrip yang diusulkan W. Andrew Loe III dalam jawabannya tidak berhasil untuk saya, jadi saya memodifikasinya sedikit dan akhirnya berhasil:
Sekarang, saya bukan semacam guru Bash, tetapi skrip benar-benar bekerja untuk kasus saya. Perhatikan, Anda harus menentukan nilai yang sesuai untuk variabel "ES_HOST" dan "NODE".
sumber
allocate
denganallocate_empty_primary
dan ganti\"allow_primary\": true
dengan\"accept_data_loss\": true
{"error":"Content-Type header [application/x-www-form-urlencoded] is not supported","status":406}
bahkan setelah menerapkan saran Fawix iniDalam kasus saya, batas atas ruang hard disk tercapai.
Lihat artikel ini: https://www.elastic.co/guide/en/elasticsearch/reference/current/disk-allocator.html
Pada dasarnya, saya berlari:
Sehingga akan mengalokasikan jika <90% ruang hard disk digunakan, dan memindahkan shard ke mesin lain di cluster jika> 95% ruang hard disk digunakan; dan memeriksa setiap 1 menit.
sumber
Mungkin itu membantu seseorang, tetapi saya memiliki masalah yang sama dan itu karena kurangnya ruang penyimpanan yang disebabkan oleh log yang terlalu besar.
Semoga ini bisa membantu seseorang! :)
sumber
Dalam kasus saya, ketika saya membuat indeks baru maka number_of_replicas default ditetapkan sebagai 1. Dan jumlah node di kluster saya hanya satu sehingga tidak ada simpul tambahan untuk membuat replika, sehingga kesehatan berubah menjadi kuning. Jadi ketika saya membuat indeks dengan properti pengaturan dan mengatur number_of_replicas sebagai 0. Kemudian itu berfungsi dengan baik. Semoga ini membantu.
sumber
Saya memiliki masalah yang sama tetapi akar penyebabnya adalah perbedaan dalam nomor versi (1.4.2 pada dua node (dengan masalah) dan 1.4.4 pada dua node (ok)). Jawaban pertama dan kedua (pengaturan "index.routing.allocation.disable_allocation" menjadi false dan pengaturan "cluster.routing.allocation.enable" to "all") tidak berfungsi.
Namun, jawaban oleh @Wilfred Hughes (pengaturan "cluster.routing.allocation.enable" menjadi "semua" menggunakan transient) memberi saya kesalahan dengan pernyataan berikut:
Setelah memperbarui node lama ke 1.4.4 node ini mulai melakukan resnc dengan node baik lainnya.
sumber
Saya juga mengalami masalah ini, dan saya menemukan cara mudah untuk menyelesaikannya.
Dapatkan indeks pecahan yang belum ditetapkan
Instal Alat kurator, dan gunakan itu untuk menghapus indeks
CATATAN: Dalam kasus saya, indeks adalah logstash hari ini 2016-04-21
sumber
curator_cli --host 127.0.0.1 delete_indices --filter_list '[{"filtertype":"pattern","kind":"prefix","value":"logstash-"}]'
Saya juga menemui situasi ini dan akhirnya memperbaikinya.
Pertama, saya akan menggambarkan situasi saya. Saya memiliki dua node dalam gugus ElasticSearch, mereka dapat menemukan satu sama lain, tetapi ketika saya membuat indeks dengan pengaturan "number_of_replicas": 2 , "number_of_shards": 5, ES menunjukkan sinyal kuning dan unassigned_shards adalah 5.
Masalahnya terjadi karena nilai number_of_replicas , ketika saya mengatur nilainya 1 , semua baik-baik saja.
sumber
Dalam kasus saya, node lama dengan share lama bergabung dengan cluster, jadi kami harus mematikan node lama dan menghapus indeks dengan pecahan yang belum ditetapkan.
sumber
Saya mencoba beberapa saran di atas dan sayangnya tidak ada yang berhasil. Kami memiliki indeks "Log" di lingkungan bawah kami tempat aplikasi menulis kesalahan mereka. Ini adalah cluster node tunggal. Apa yang dipecahkan untuk saya adalah memeriksa file konfigurasi YML untuk node dan melihat bahwa ia masih memiliki pengaturan default "gateway.expected_nodes: 2". Ini mengesampingkan pengaturan lain yang kami miliki. Setiap kali kita membuat indeks pada node ini, ia akan mencoba untuk menyebarkan 3 dari 5 pecahan ke phantom 2nd node. Ini karena itu akan muncul sebagai tidak ditetapkan dan mereka tidak pernah bisa dipindahkan ke node 1 dan hanya.
Solusinya adalah mengedit konfigurasi, mengubah pengaturan "gateway.expected_nodes" menjadi 1, sehingga akan berhenti mencari saudara lelakinya yang tidak pernah ditemukan di cluster, dan memulai kembali instance layanan elastis. Juga, saya harus menghapus indeks, dan membuat yang baru. Setelah membuat indeks, semua pecahan muncul pada simpul 1 dan satu-satunya, dan tidak ada yang tidak ditetapkan.
sumber
Bagi saya, ini diselesaikan dengan menjalankan ini dari konsol dev: "POST / _cluster / reroute? Retry_failed"
.....
Saya mulai dengan melihat daftar indeks untuk melihat indeks mana yang merah dan kemudian berlari
"dapatkan /_cat/shards?h=[INDEXNAME[,shard,prirep,state,unassigned.reason"
dan melihat bahwa pecahannya macet dalam keadaan ALLOCATION_FAILED, jadi menjalankan coba lagi di atas menyebabkan mereka mencoba ulang alokasi.
sumber
Mungkin bisa membantu, tetapi saya mengalami masalah ini ketika mencoba menjalankan ES dalam mode tertanam. Perbaiki adalah untuk memastikan Node memiliki set lokal (benar).
sumber
Alasan lain yang mungkin untuk pecahan yang belum ditetapkan adalah bahwa kluster Anda menjalankan lebih dari satu versi biner Elasticsearch.
Ini bisa menjadi akar penyebab pecahan yang belum ditetapkan.
Dokumentasi Elastis - Proses Peningkatan Bergulir
sumber
Saya mengalami masalah yang sama persis. Ini dapat dicegah dengan mengatur sementara alokasi shard menjadi false sebelum memulai kembali elasticsearch, tetapi ini tidak memperbaiki pecahan yang belum ditetapkan jika sudah ada.
Dalam kasus saya itu disebabkan oleh kurangnya ruang disk kosong pada node data. Pecahan yang belum ditetapkan di mana masih pada node data setelah restart tetapi mereka di mana tidak dikenali oleh master.
Hanya dengan membersihkan 1 node dari disk, proses replikasi dimulai untuk saya. Ini adalah proses yang agak lambat karena semua data harus disalin dari 1 node data ke yang lain.
sumber
Saya mencoba untuk menghapus pecahan yang belum ditetapkan atau secara manual menetapkannya ke simpul data tertentu. Itu tidak berhasil karena pecahan yang tidak ditugaskan terus muncul dan status kesehatan "merah" berulang-ulang. Kemudian saya perhatikan bahwa salah satu data node terjebak dalam keadaan "restart". Saya mengurangi jumlah data node, membunuhnya. Masalahnya tidak dapat direproduksi lagi.
sumber
Saya memiliki dua indeks dengan pecahan yang belum ditentukan yang tampaknya tidak sembuh sendiri. Saya akhirnya menyelesaikan ini dengan menambahkan sementara data-node [1] . Setelah indeks menjadi sehat dan semuanya stabil menjadi hijau, saya menghapus simpul ekstra dan sistem mampu menyeimbangkan kembali (lagi) dan menetap pada kondisi yang sehat.
Ini adalah ide yang baik untuk menghindari membunuh banyak data node sekaligus (itulah cara saya masuk ke keadaan ini). Kemungkinan besar, saya gagal menyimpan salinan / replika untuk setidaknya satu dari pecahan. Untungnya, Kubernetes menyimpan penyimpanan disk, dan menggunakannya kembali ketika saya meluncurkan kembali data-node.
... Beberapa waktu telah berlalu ...
Nah, kali ini hanya menambahkan simpul sepertinya tidak berfungsi (setelah menunggu beberapa menit untuk sesuatu terjadi), jadi saya mulai mencari-cari di REST API.
Ini menunjukkan simpul baru saya dengan
"decision": "YES"
.By the way, semua node yang sudah ada sebelumnya
"decision": "NO"
karena"the node is above the low watermark cluster setting"
. Jadi ini mungkin kasus yang berbeda dari yang saya bahas sebelumnya.Lalu aku membuat POST sederhana berikut [2] tanpa tubuh , yang menendang hal ke gigi ...
Catatan lain:
Sangat membantu: https://datadoghq.com/blog/elasticsearch-unassigned-shards
Hal lain yang mungkin berhasil. Setel
cluster_concurrent_rebalance
ke0
, lalu kenull
- seperti yang saya tunjukkan di sini .[1] Cukup mudah dilakukan di Kubernetes jika Anda memiliki ruang kepala yang cukup: cukup gunakan set stateful melalui dasbor.
[2] Dengan menggunakan antarmuka "Dev Tools" Kibana, saya tidak perlu repot dengan shell SSH / exec.
sumber
Saya baru saja meningkatkan
oleh 1 (tunggu sampai node disinkronkan) kemudian turunkan dengan 1 setelahnya, yang secara efektif menghilangkan pecahan yang tidak ditugaskan dan cluster berwarna Hijau lagi tanpa risiko kehilangan data apa pun.
Saya percaya ada cara yang lebih baik tetapi ini lebih mudah bagi saya.
Semoga ini membantu.
sumber
Saat berurusan dengan pecahan yang rusak Anda dapat mengatur faktor replikasi ke 0 dan kemudian mengaturnya kembali ke nilai aslinya. Ini akan menghapus sebagian besar jika tidak semua pecahan Anda rusak dan memindahkan replika baru di cluster.
Menyetel indeks dengan replika yang belum ditetapkan untuk menggunakan faktor replikasi 0:
Mengaturnya kembali ke 1:
Catatan: Jangan jalankan ini jika Anda memiliki faktor replikasi yang berbeda untuk indeks yang berbeda. Ini akan membuat hardcode faktor replikasi untuk semua indeks menjadi 1.
sumber