Mari kita mulai dengan sedikit latar belakang. Di perusahaan kami, sebuah proyek sedang dalam pemeliharaan, yang sampai saat ini masih dalam tahap pengujian / pengembangan. Pada saat itu, digunakan ClickHouse dengan 3 pecahan, masing-masing 2 replika. Mempertimbangkan bahwa infrastruktur proyek ini adalah uji dan tidak memerlukan otorisasi tambahan (ClickHouse berada di segmen tertutup), tidak ada yang mengajukan pertanyaan ini.
Seiring berjalannya waktu, proyek ini berkembang, ClickHouse menjadi basis produksi dan kami memigrasikan data dari infrastruktur lama ke infrastruktur baru dengan 1 shard, 3 replika di 3 server yang berbeda (ClickHouse di-host di Kubernetes berdasarkan StatefulSets) dan, tentu saja, dengan otorisasi.
Inilah yang terjadi selanjutnya.
Hampir segera setelah memulai proyek dalam produksi, kami menemukan bahwa dalam datadir ClickHouse dari database pengguna, dalam tabel non-shard (dalam kasus kami, yang terletak secara lokal pada setiap node, tanpa postfix yang diiris, dari tipe Terdistribusi), ada sejumlah besar tidak hilang bin-log. Tanggal log mendahului tanggal instalasi pada otorisasi ClickHouse.
Berikut ini adalah output konsol untuk salah satu replika table table_1 dari database pengujian ClickHouse:
ls -l /var/lib/clickhouse/data/test/table_1/test_usr@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000 | tail -n 10 -rw-r----- 1 clickhouse clickhouse 1472 Jul 8 08:26 9983.bin -rw-r----- 1 clickhouse clickhouse 1453 Jul 8 08:26 9985.bin -rw-r----- 1 clickhouse clickhouse 1383 Jul 8 08:26 9987.bin -rw-r----- 1 clickhouse clickhouse 1461 Jul 8 08:27 9989.bin -rw-r----- 1 clickhouse clickhouse 1458 Jul 8 08:28 9991.bin -rw-r----- 1 clickhouse clickhouse 1468 Jul 8 08:29 9993.bin -rw-r----- 1 clickhouse clickhouse 1413 Jul 8 08:29 9995.bin -rw-r----- 1 clickhouse clickhouse 1509 Jul 8 08:32 9997.bin -rw-r----- 1 clickhouse clickhouse 1504 Jul 8 08:32 9999.bin drwxr-x--- 2 clickhouse clickhouse 4096 Sep 16 12:59 tmp
Yaitu data itu sendiri ditempatkan di tabel Terdistribusi lokal dari replika tertentu, tetapi untuk alasan yang tidak diketahui pada saat itu, itu tidak dipindahkan ke tabel dengan postfix yang di-shard (seperti ReplicatedMergeTree), yang dapat diakses dari semua replika klaster dengan mengaksesnya melalui tabel lokal (tanpa postfix) beling).
Ternyata setelah analisis, data yang dicatat dalam database ClickHouse pada infrastruktur lama, yaitu sebelum memungkinkan otorisasi, mereka tidak dapat lagi didistribusikan di antara replika pada infrastruktur baru, karena Di server ClickHouse baru, otorisasi telah diaktifkan.
Kenapa begitu. Ketika data ditulis ke ClickHouse tanpa otorisasi, tautan dari formulir berikut ini dihasilkan di direktori datadir clickHouse di direktori basis data dan tabel yang sesuai (tautan dihasilkan berdasarkan permintaan yang dibuat ke database):
test_usr@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000
Mari kita lihat lebih detail. Tautan di atas diakses oleh pengguna test_usr, tetapi kata sandi untuk otorisasi tidak ditentukan. Dan apa yang terjadi, jika sebelum mengaktifkan otorisasi dalam database, sejumlah besar data dicatat di ClickHouse, yang membentuk log bin, dan ClickHouse di server lama tidak punya waktu untuk kehilangan mereka, maka setelah mengaktifkan otorisasi pada server ClickHouse baru dan migrasi lama tidak hilang bin-log ke server baru, bin-log ini tidak bisa lagi dimainkan, karena tautan telah dibuat tanpa otorisasi untuk pengguna test_usr.
Semua data masuk baru di ClickHouse juga akan menghasilkan bin-log di direktori dan tabel basis data yang sesuai, yang kemudian akan diputar, tetapi dengan tautan yang berbeda, di mana otorisasi ditunjukkan (karena aplikasi sudah mengakses ClickHouse pada infrastruktur baru) dibuat dengan kata sandi untuk pengguna test_usr, jika tidak permintaan tidak akan mencapai basis data):
test_usr:password@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000
Karena data ditulis ke basis data secara tidak sinkron, yaitu, mereka pertama kali ditempatkan pada satu replika ClickHouse lokal yang diakses, dan hanya kemudian mereka dikirim ke replika lain dari gugus.
Akibatnya, data lama yang direkam pada salah satu replika ClickHouse lokal, tetapi tidak didistribusikan di antara sisa replika cluster (karena tautan yang dihasilkan tidak berisi kata sandi untuk pengguna, tetapi sudah ditetapkan), mereka bahkan tidak dapat diakses untuk membaca replika tempat log-bin yang tidak teraplikasi ditempatkan secara langsung.
Bagaimana kami memecahkan masalah dan tidak kehilangan data yang tidak terisi?
Semuanya ternyata sangat sederhana. Cukup untuk melakukan manipulasi berikut dengan data yang tidak terisi dalam database:
- Tautan yang dihasilkan untuk masing-masing tabel dari database masalah harus diganti namanya (diganti namanya) ke formulir yang diperlukan:
mv /var/lib/clickhouse/data/test/table_1/test_usr@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000 /var/lib/clickhouse/data/test/table_1/test_usr:password@clickhouse%2D0%2Eclickhouse%2Eclickhouse%2Dprod%2Esvc%2Ecluster%2Elocal\:9000
- Mulai ulang replika ClickHouse, yang memulai proses pemutaran log tempat sampah dan menempatkannya di tabel sharded kami (ReplicatedMergeTree).
PS : Saya menyarankan semua orang untuk memeriksa operasi server ClickHouse mereka untuk masalah yang dijelaskan. Jika ini ditemukan, maka catatan ini akan membantu Anda menghemat waktu mencari solusi dan lebih berhati-hati saat mengatur / mengubah kata sandi di ClickHouse di masa depan.
Baca juga artikel lain di blog kami: