Apache Kafka Verilerini CentOS 7 Üzerinde Yedekleme, İçeri Aktarma ve Taşıma Rehberi
Giriş
Günümüzün veri odaklı dünyasında, gerçek zamanlı veri akış platformları işletmeler için hayati öneme sahiptir. Apache Kafka, yüksek performanslı, dağıtık ve dayanıklı bir mesajlaşma sistemi olarak bu platformların başında gelmektedir. Finans, perakende, IoT ve birçok diğer sektörde kritik iş süreçlerinin temelini oluşturan Kafka, sürekli veri akışını yönetir. Ancak, herhangi bir kritik sistemde olduğu gibi, Kafka verilerinin güvenliğini sağlamak, olası veri kayıplarını önlemek ve sistem sürekliliğini temin etmek için düzenli yedekleme, etkili veri içeri aktarma ve sorunsuz taşıma stratejileri vazgeçilmezdir.
CentOS 7, sunucu ortamlarında yaygın olarak kullanılan kararlı ve güvenilir bir işletim sistemidir. Bu makale, CentOS 7 üzerinde çalışan bir Apache Kafka kümesindeki verileri nasıl yedekleyeceğinizi, yedeklenen verileri nasıl geri yükleyeceğinizi ve Kafka verilerini veya broker’larını farklı senaryolarda nasıl taşıyacağınızı adım adım açıklamaktadır. Amacımız, veri bütünlüğünü korurken operasyonel kesintileri en aza indiren pratik ve güvenilir yöntemler sunmaktır.
Ön Koşullar ve Hazırlık
Bu rehberdeki adımları uygulayabilmek için aşağıdaki ön koşulların sağlanmış olması gerekmektedir:
* CentOS 7 İşletim Sistemi: En az bir adet CentOS 7 sunucusu kurulu ve güncel olmalıdır.
* Java Geliştirme Kiti (JDK): Apache Kafka Java tabanlı olduğu için, sunucuda uygun bir JDK sürümünün (tercihen OpenJDK 8 veya üzeri) yüklü olması gerekmektedir.
sudo yum install java-1.8.0-openjdk-devel -y
* Apache Kafka ve ZooKeeper Kurulumu: CentOS 7 üzerinde çalışan bir Apache Kafka kümesi ve onun bağımlılığı olan ZooKeeper’ın kurulu ve yapılandırılmış olması gerekmektedir. Bu rehber, Kafka’nın /opt/kafka dizinine kurulduğunu ve veri dizinlerinin varsayılan olarak /tmp/kafka-logs veya özel bir dizinde (/data/kafka) bulunduğunu varsayacaktır. Kendi kurulum yolunuza göre komutları ayarlamanız gerekebilir.
* Yeterli Disk Alanı: Yedekleme ve taşıma işlemleri için kaynak ve hedef sistemlerde yeterli disk alanı bulunduğundan emin olun. Yedeklenecek veya taşınacak verinin en az iki katı kadar boş alan önerilir.
* Ağ Bağlantısı: Kümeler arası taşıma işlemleri için sunucular arasında stabil ve hızlı bir ağ bağlantısı gereklidir.
* Kök veya Sudo Yetkisi: Gerekli dosya sistemi işlemleri ve servis yönetimi için root yetkisi veya sudo kullanma yetkisi olmalıdır.
* Güvenlik Duvarı Ayarları: Kafka ve ZooKeeper’ın kullandığı portların (varsayılan olarak Kafka için 9092, ZooKeeper için 2181) sunucular arası iletişim için açık olduğundan emin olun.
Apache Kafka Verilerini Yedekleme
Kafka verilerini yedeklemenin farklı yaklaşımları vardır. Seçim, veri kaybı toleransınıza, kurtarma süresi hedeflerinize (RTO) ve kurtarma noktası hedeflerinize (RPO) bağlıdır.
1. Dosya Sistemi Seviyesinde Yedekleme (Offline Yedekleme)
Bu yöntem, Kafka broker’ının veri dizinlerinin doğrudan kopyalanmasını içerir. Veri tutarlılığı sağlamak için Kafka broker’larının durdurulması gerekmektedir. Bu, en basit ve en güvenilir yedekleme yöntemlerinden biridir, ancak sistemde kısa süreli bir kesinti gerektirir.
Adımlar:
1. Kafka Broker’ını Durdurma: Veri tutarlılığını sağlamak için yedekleme işlemine başlamadan önce ilgili Kafka broker’ını veya tüm kümedeki broker’ları durdurun.
sudo systemctl stop kafka
# Veya manuel olarak:
/opt/kafka/bin/kafka-server-stop.sh
ZooKeeper’ı durdurmanıza gerek yoktur, çünkü Kafka verileri ZooKeeper’da değil, broker’ların disklerinde tutulur. Ancak, eğer ZooKeeper verilerini de yedeklemek isterseniz, onu da durdurup veri dizinini (dataDir içinde belirtilen) yedekleyebilirsiniz.
2. Kafka Veri Dizinlerini Belirleme: Kafka broker’ınızın server.properties dosyasında log.dirs parametresi ile belirtilen veri dizinlerini bulun. Varsayılan olarak bu /tmp/kafka-logs olabilir, ancak üretim ortamlarında genellikle özel bir dizin (/data/kafka) kullanılır.
grep "log.dirs" /opt/kafka/config/server.properties
# Örnek çıktı: log.dirs=/data/kafka/kafka-logs
Bu örnekte, /data/kafka/kafka-logs dizini yedeklenecek ana dizindir.
3. Veri Dizinlerini Yedekleme: rsync veya cp komutlarını kullanarak veri dizinlerini güvenli bir yedekleme konumuna kopyalayın. rsync, büyük dizinler ve artımlı yedeklemeler için daha uygundur.
* Tam Yedekleme (rsync ile):
sudo rsync -avh --progress /data/kafka/kafka-logs /mnt/backup/kafka_data_$(date +%Y%m%d%H%M%S)
Bu komut, /data/kafka/kafka-logs dizinini, tarih ve saat damgası içeren yeni bir dizin altında /mnt/backup konumuna kopyalar. --progress ilerlemeyi gösterir, -a arşiv modunu (izinler, sahiplik vb. korur), -v ayrıntılı çıktıyı ve -h insan tarafından okunabilir boyutları sağlar.
* Tam Yedekleme (cp ile):
sudo cp -rp /data/kafka/kafka-logs /mnt/backup/kafka_data_$(date +%Y%m%d%H%M%S)
-r özyinelemeli kopyalama, -p izinleri ve zaman damgalarını korur.
4. Kafka Broker’ını Başlatma: Yedekleme işlemi tamamlandıktan sonra Kafka broker’ını tekrar başlatın.
sudo systemctl start kafka
# Veya manuel olarak:
/opt/kafka/bin/kafka-server-start.sh -daemon /opt/kafka/config/server.properties
LVM Anlık Görüntüleri (Snapshot) ile Yedekleme (İsteğe Bağlı):
Eğer Kafka veri dizinleriniz Logical Volume Manager (LVM) tarafından yönetilen bir disk bölümündeyse, broker’ı durdurmaya gerek kalmadan tutarlı bir anlık görüntü alabilirsiniz. Bu, anlık görüntü alırken kısa bir süre için I/O’yu dondurur, ancak broker’ı tamamen durdurmaktan daha az kesinti yaratır.
1. LVM Anlık Görüntüsü Oluşturma:
sudo lvcreate --size 10G --snapshot --name kafka_snapshot /dev/vg_kafka/lv_kafka_data
Burada /dev/vg_kafka/lv_kafka_data, Kafka verilerinin bulunduğu mantıksal birimdir. 10G, anlık görüntünün boyutu için yeterli bir yer olmalıdır.
2. Anlık Görüntüyü Bağlama ve Yedekleme:
sudo mount /dev/vg_kafka/kafka_snapshot /mnt/kafka_snapshot
sudo rsync -avh --progress /mnt/kafka_snapshot/kafka-logs /mnt/backup/kafka_data_$(date +%Y%m%d%H%M%S)
3. Anlık Görüntüyü Ayırma ve Silme:
sudo umount /mnt/kafka_snapshot
sudo lvremove /dev/vg_kafka/kafka_snapshot
2. Mantıksal Yedekleme (Topic Bazında Veri Dışa Aktarma)
Bu yöntem, belirli topic’lerdeki verileri bir dosyaya aktarmak için Kafka’nın kafka-console-consumer aracını kullanır. Bu, tüm kümenin yedeklenmesinden ziyade belirli topic’leri veya veri alt kümelerini yedeklemek için kullanışlıdır. Kesinti gerektirmez, ancak büyük topic’ler için pratik olmayabilir ve mesaj offsetlerini korumaz.
Adımlar:
1. Topic Verilerini Dışa Aktarma: kafka-console-consumer kullanarak belirli bir topic’teki tüm mesajları standart çıktıya yönlendirin ve bir dosyaya kaydedin.
/opt/kafka/bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 \
--topic my_topic --from-beginning --property print.timestamp=true \
--property print.key=true --property print.value=true > /mnt/backup/my_topic_backup_$(date +%Y%m%d%H%M%S).txt
* --bootstrap-server: Kafka broker’ının adresi.
* --topic: Yedeklenecek topic’in adı.
* --from-beginning: Topic’in en başından itibaren tüm mesajları okur.
* --property print.timestamp=true, --property print.key=true, --property print.value=true: Mesajın zaman damgasını, anahtarını ve değerini çıktıda gösterir. Bu, geri yükleme sırasında veri bütünlüğünü sağlamak için önemlidir.
2. Alternatif (Avro, JSON formatları için): Eğer verileriniz belirli bir formatta (Avro, JSON) ise, bunları işleyebilen özel bir consumer uygulaması yazmak veya Kafka Connect gibi araçları kullanmak daha uygun olabilir.
Apache Kafka Verilerini İçeri Aktarma (Geri Yükleme)
Yedeklenen Kafka verilerini geri yüklemek, yedekleme yöntemine bağlı olarak farklılık gösterir.
1. Dosya Sistemi Seviyesinde Geri Yükleme
Bu yöntem, daha önce alınan dosya sistemi yedeğini kullanarak bir Kafka broker’ını veya kümesini önceki bir duruma geri döndürmek için kullanılır.
Adımlar:
1. Kafka Broker’ını Durdurma: Geri yükleme işlemine başlamadan önce hedef Kafka broker’ını durdurun.
sudo systemctl stop kafka
2. Mevcut Veri Dizinlerini Temizleme (İsteğe Bağlı/Dikkatli): Eğer tamamen temiz bir geri yükleme yapıyorsanız, mevcut Kafka veri dizinlerini silmeniz veya başka bir yere taşımanız gerekebilir. Bu adım dikkatli yapılmalıdır, çünkü yanlış dizinleri silmek veri kaybına yol açabilir.
sudo rm -rf /data/kafka/kafka-logs/*
Veya daha güvenli bir şekilde, mevcut dizini yeniden adlandırın:
sudo mv /data/kafka/kafka-logs /data/kafka/kafka-logs_old
sudo mkdir -p /data/kafka/kafka-logs
sudo chown kafka:kafka /data/kafka/kafka-logs # Kullanıcı ve grup izinlerini ayarlayın
3. Yedeklenen Verileri Kopyalama: Yedekleme konumundan, yedeklenen Kafka veri dizinlerini (kafka-logs) orijinal konumuna (/data/kafka/kafka-logs) kopyalayın.
sudo rsync -avh --progress /mnt/backup/kafka_data_YYYYMMDDHHMMSS/kafka-logs/ /data/kafka/kafka-logs/
Kaynak dizinin sonundaki / işareti önemlidir; bu, dizinin içeriğinin kopyalanmasını sağlar, dizinin kendisinin değil.
4. İzinleri Kontrol Etme: Kafka’nın veri dizinlerine erişim için doğru kullanıcı ve grup izinlerine sahip olduğundan emin olun. Genellikle bu kafka kullanıcısı ve grubudur.
sudo chown -R kafka:kafka /data/kafka/kafka-logs
5. Kafka Broker’ını Başlatma: Veriler kopyalandıktan ve izinler ayarlandıktan sonra Kafka broker’ını başlatın.
sudo systemctl start kafka
Broker, yedeklenen verilerle birlikte başlayacaktır.
2. Mantıksal Veri İçeri Aktarma
Daha önce kafka-console-consumer ile dışa aktarılan topic verilerini geri yüklemek için kafka-console-producer kullanılır.
Adımlar:
1. Hedef Topic’i Oluşturma (Gerekliyse): Eğer hedef topic mevcut değilse, öncelikle onu oluşturmanız gerekmektedir.
/opt/kafka/bin/kafka-topics.sh --create --topic my_topic_restored --bootstrap-server localhost:9092 \
--partitions 3 --replication-factor 1
2. Verileri İçeri Aktarma: Yedeklenen dosyayı kafka-console-producer aracılığıyla hedef topice gönderin. Eğer mesaj anahtarları ve zaman damgaları yedekleme sırasında kaydedildiyse, bunları da doğru şekilde işlemek için producer yapılandırmasını ayarlamanız gerekebilir.
cat /mnt/backup/my_topic_backup_YYYYMMDDHHMMSS.txt | /opt/kafka/bin/kafka-console-producer.sh \
--broker-list localhost:9092 --topic my_topic_restored \
--property parse.key=true --property key.separator=":" --property parse.timestamp=true --property timestamp.format="yyyy-MM-dd'T'HH:mm:ss.SSSZ"
Not: Yukarıdaki örnek, print.key=true ve print.timestamp=true ile yedeklenen formatı varsaymaktadır. parse.key ve parse.timestamp property’leri, producer’ın bu bilgileri ayrıştırmasını sağlar. Yedekleme dosyasının formatına göre bu property’leri ve ayırıcıları (key.separator) ayarlamanız gerekebilir.
3. Veri Bütünlüğünü Doğrulama: İçeri aktarma işleminden sonra, verilerin doğru bir şekilde aktarıldığını doğrulamak için kafka-console-consumer ile hedef topic’ten bazı mesajları okuyun ve orijinal verilerle karşılaştırın.
Apache Kafka Verilerini Taşıma (Migration)
Kafka verilerini taşıma, farklı senaryoları kapsar: bir broker’ı yeni bir sunucuya taşımak, topic partition’larını küme içindeki farklı broker’lara dağıtmak veya iki ayrı Kafka kümesi arasında veri senkronizasyonu yapmak.
1. Offline Broker Taşıma (Yeni Sunucuya veya Dizinlere)
Bu yöntem, bir Kafka broker’ının tüm verilerini yeni bir sunucuya veya mevcut sunucudaki farklı bir disk dizinine taşımak için kullanılır. Bu, dosya sistemi yedeklemesine benzer şekilde bir kesinti gerektirir.
Adımlar:
1. Kafka Broker’ını Durdurma: Taşınacak broker’ı durdurun.
sudo systemctl stop kafka
2. Veri Dizinlerini Kopyalama: Mevcut log.dirs dizinlerinin içeriğini yeni hedef konuma kopyalayın.
* Aynı Sunucuda Dizin Değişikliği:
sudo rsync -avh --progress /old/data/kafka-logs/ /new/data/kafka-logs/
* Yeni Sunucuya Taşıma (SCP ile):
sudo scp -rp /data/kafka/kafka-logs user@new_server_ip:/data/kafka/kafka-logs
Bu komut, tüm veri dizinini yeni sunucudaki hedef konuma kopyalar. Yeni sunucuda aynı dizin yapısının ve izinlerin olduğundan emin olun.
3. server.properties Dosyasını Güncelleme: Kafka broker’ının server.properties dosyasında log.dirs parametresini yeni veri dizini yolunu gösterecek şekilde güncelleyin. Eğer broker ID (broker.id) de değişiyorsa, bunu da güncelleyin.
# Eski: log.dirs=/old/data/kafka-logs
# Yeni:
log.dirs=/new/data/kafka-logs
4. İzinleri Kontrol Etme: Yeni dizinde veya yeni sunucuda Kafka kullanıcısı için doğru izinlerin ayarlandığından emin olun.
sudo chown -R kafka:kafka /new/data/kafka-logs
5. Kafka Broker’ını Başlatma: Broker’ı yeni yapılandırma ile başlatın.
sudo systemctl start kafka
Eğer broker ID değiştiyse, ZooKeeper’daki eski broker ID’sine ait meta veriler otomatik olarak güncellenecektir.
2. Online Broker Taşıma ve Küme Genişletme (Partition Reassignment)
Bu yöntem, mevcut Kafka kümesindeki topic partition’larını aktif olarak çalışan broker’lar arasında yeniden dağıtmak veya yeni eklenen broker’lara taşımak için kullanılır. Bu işlem online olarak ve kesintisiz bir şekilde gerçekleştirilebilir.
Adımlar:
1. Hedef Broker’ları Ekleme (Gerekliyse): Eğer yeni broker’lara taşıyorsanız, öncelikle bu broker’ları kümeye ekleyin ve başlatın.
2. Taşıma Planı Oluşturma: kafka-reassign-partitions.sh aracını kullanarak taşınacak topic’leri ve partition’ları içeren bir JSON dosyası oluşturun.
* JSON Giriş Dosyası (topics-to-move.json) Oluşturma:
{
"topics": [
{
"topic": "my_topic_1"
},
{
"topic": "my_topic_2"
}
],
"version": 1
}
Bu dosya, taşınacak topic’leri belirtir.
* Taşıma Adayı Planı Oluşturma: Bu komut, belirtilen topic’lerin partition’larını yeni broker’lara veya mevcut broker’lar arasında nasıl dağıtılacağına dair bir JSON planı önerir.
/opt/kafka/bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
--topics-to-move-json-file topics-to-move.json \
--broker-list "1,2,3,4" --generate
* --broker-list: Partition’ların dağıtılacağı broker ID’lerinin virgülle ayrılmış listesi.
* --generate: Mevcut atamayı (Current partition replica assignment) ve önerilen atamayı (Proposed partition replica assignment) içeren bir JSON çıktısı üretir.
Örnek Çıktı:
Current partition replica assignment
{"version":1,"partitions":[{"topic":"my_topic_1","partition":0,"replicas":[1,2],"log_dirs":["any","any"]},{"topic":"my_topic_1","partition":1,"replicas":[2,3],"log_dirs":["any","any"]}]}
Proposed partition replica assignment
{"version":1,"partitions":[{"topic":"my_topic_1","partition":0,"replicas":[3,4],"log_dirs":["any","any"]},{"topic":"my_topic_1","partition":1,"replicas":[4,1],"log_dirs":["any","any"]}]}
Proposed partition replica assignment kısmını kopyalayıp reassignment-plan.json adlı yeni bir dosyaya kaydedin.
3. Taşıma İşlemini Başlatma: Oluşturulan reassignment-plan.json dosyasını kullanarak taşıma işlemini başlatın.
/opt/kafka/bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
--reassignment-json-file reassignment-plan.json --execute
4. Taşıma Durumunu Doğrulama: Taşıma işleminin ilerlemesini ve tamamlandığını kontrol etmek için aynı komutu --verify parametresiyle çalıştırın.
/opt/kafka/bin/kafka-reassign-partitions.sh --bootstrap-server localhost:9092 \
--reassignment-json-file reassignment-plan.json --verify
Tüm partition’lar taşındığında “Reassignment of partitions completed successfully” mesajını göreceksiniz.
Önemli Notlar:
* Taşıma işlemi sırasında ağ ve disk I/O’su artabilir, bu da broker performansını etkileyebilir.
* Replikasyon faktörünü değiştirmek için de bu aracı kullanabilirsiniz.
3. Kümeler Arası Veri Taşıma (MirrorMaker ile)
Apache Kafka MirrorMaker, bir Kafka kümesindeki topic’leri başka bir Kafka kümesine asenkron olarak yansıtan bir araçtır. Bu, felaket kurtarma (DR), küme yükseltmeleri veya coğrafi olarak dağıtılmış veri merkezleri arasında veri replikasyonu için idealdir.
MirrorMaker 1 (Eski Sürüm): Kafka dağıtımının bir parçası olarak gelir. Consumer ve Producer API’lerini kullanır.
Adımlar:
1. Yapılandırma Dosyalarını Hazırlama: MirrorMaker’ın çalışacağı sunucuda (genellikle hedef kümenin yakınında) iki yapılandırma dosyası oluşturun:
* consumer.properties (Kaynak Kümeden Okuma İçin):
bootstrap.servers=source_kafka_broker_1:9092,source_kafka_broker_2:9092
group.id=mirrormaker_consumer_group
exclude.internal.topics=true
* producer.properties (Hedef Kümeye Yazma İçin):
bootstrap.servers=target_kafka_broker_1:9092,target_kafka_broker_2:9092
acks=all
2. MirrorMaker’ı Başlatma:
/opt/kafka/bin/kafka-mirror-maker.sh --consumer.config config/consumer.properties \
--producer.config config/producer.properties --whitelist "topic_to_mirror|another_topic"
--whitelist: Yansıtılacak topic’leri belirten bir düzenli ifade (regex). . tüm topic’leri yansıtır.
MirrorMaker 2.0 (Kafka Connect Tabanlı): Kafka 2.4 ve üzeri sürümlerde tanıtılan MirrorMaker 2.0, Kafka Connect çerçevesi üzerine inşa edilmiştir ve daha güçlü, ölçeklenebilir ve esnek bir replikasyon çözümü sunar.
Adımlar:
1. Yapılandırma Dosyasını Hazırlama (mm2.properties):
# Genel MirrorMaker yapılandırması
clusters = source, target
source.bootstrap.servers = source_kafka_broker_1:9092
target.bootstrap.servers = target_kafka_broker_1:9092
# Replikasyon ayarları
source->target.enabled = true
source->target.topics = .*
source->target.replication.factor = 1 # Hedef kümedeki topic'ler için replikasyon faktörü
source->target.consumer.group.filters = .* # Consumer gruplarını da replike etmek için
source->target.sync.group.offsets = true # Consumer offsetlerini senkronize etmek için
2. MirrorMaker 2.0’ı Başlatma:
/opt/kafka/bin/connect-mirror-maker.sh config/mm2.properties
MirrorMaker 2.0, Kafka Connect worker’ı olarak çalışır ve birden fazla connector’ı yönetir (source, sink, checkpoint, offset sync).
Önemli Notlar:
* MirrorMaker, topic adlarını hedef kümede genellikle kaynak küme adıyla ön ekler (örn. source.my_topic). Bu davranışı yapılandırmak mümkündür.
* MirrorMaker 2.0, çok daha esnek ve yönetilebilir olup, uzun vadeli replikasyon stratejileri için tercih edilmelidir.
Veri Bütünlüğü ve Doğrulama
Yedekleme, geri yükleme veya taşıma işlemlerinden sonra verilerin bütünlüğünü ve doğruluğunu doğrulamak kritik öneme sahiptir.
1. Topic Mesaj Sayılarını Karşılaştırma:
Kaynak ve hedef topic’lerdeki mesaj sayılarını karşılaştırın.
/opt/kafka/bin/kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list localhost:9092 --topic my_topic --time -1
Bu komut, topic’in en son offset’ini verir. Partition bazında detaylı kontrol için kafka-consumer-groups.sh kullanılabilir.
2. Consumer Offsetlerini Kontrol Etme:
Eğer consumer gruplarını da taşıdıysanız veya senkronize ettiyseniz, onların offsetlerini kontrol edin.
/opt/kafka/bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group my_consumer_group
3. Örnek Veri Çekme ve Karşılaştırma:
Kaynak ve hedef topic’lerden belirli bir miktar mesajı okuyun ve içeriklerini karşılaştırın.
/opt/kafka/bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 \
--topic my_topic --from-beginning --max-messages 100 > source_data.txt
/opt/kafka/bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 \
--topic my_topic_restored --from-beginning --max-messages 100 > target_data.txt
diff source_data.txt target_data.txt
4. Kafka Metriklerini İzleme:
Taşıma veya geri yükleme sonrası Kafka broker’larının performans metriklerini (CPU, bellek, disk I/O, ağ trafiği, gecikme süreleri) izleyin. JMX, Prometheus/Grafana veya diğer izleme araçları kullanılabilir.
En İyi Uygulamalar ve Önemli Hususlar
* Yedekleme ve Taşıma Planlarını Test Edin: Üretim ortamında herhangi bir işlem yapmadan önce, tüm yedekleme, geri yükleme ve taşıma prosedürlerini bir test ortamında titizlikle uygulayın ve doğrulayın.
* Veri Tutarlılığı ve Kayıp Toleransı: İşletmenizin veri kaybı toleransını (RPO) ve kurtarma süresi hedeflerini (RTO) net bir şekilde belirleyin. Bu hedefler, hangi yedekleme ve taşıma stratejisinin sizin için en uygun olduğunu belirleyecektir.
* Güvenlik: Yedekleme dosyalarını ve taşıma sırasında kullanılan kimlik bilgilerini güvenli bir şekilde saklayın. Kafka ACL’lerini ve şifrelemeyi kullanarak veri güvenliğini sağlayın.
* Kaynak Planlaması: Yedekleme ve taşıma işlemleri sırasında ek disk alanı, ağ bant genişliği ve CPU kaynaklarına ihtiyaç duyulabilir. Bu kaynakları önceden planlayın.
* Otomasyon: Yedekleme işlemlerini otomatikleştirmek için cron işleri veya yapılandırma yönetim araçları (Ansible, Puppet) kullanın. Bu, insan hatasını azaltır ve süreçleri standartlaştırır.
* ZooKeeper’ın Rolü: Kafka’nın meta verileri (topic yapılandırması, partition atamaları, consumer offsetleri) ZooKeeper’da saklanır. Kafka verilerini yedeklerken ZooKeeper verilerini de yedeklemeyi düşünebilirsiniz, ancak genellikle Kafka broker’larının veri dizinleri birincil yedekleme hedefidir.
* Kafka Sürüm Uyumluluğu: Kümeler arası taşıma veya yükseltme yaparken Kafka sürüm uyumluluğunu göz önünde bulundurun. MirrorMaker 2.0, farklı Kafka sürümleri arasında replikasyon için daha esnektir.
* Belgeleme: Tüm yedekleme ve taşıma prosedürlerini, yapılandırma dosyalarını ve alınan kararları detaylı bir şekilde belgeleyin. Bu, gelecekteki operasyonlar ve sorun giderme için kritik öneme sahiptir.
Sonuç
Apache Kafka, modern veri mimarilerinin temel taşıdır ve bu platformdaki verilerin güvenliği ve erişilebilirliği iş sürekliliği için hayati öneme sahiptir. CentOS 7 üzerinde Kafka verilerini yedekleme, içeri aktarma ve taşıma, farklı operasyonel ihtiyaçlara yönelik çeşitli yöntemler sunar. Dosya sistemi tabanlı offline yedeklemeden, kafka-reassign-partitions.sh ile online küme genişletmeye ve MirrorMaker ile kümeler arası replikasyona kadar, her yöntemin kendine özgü avantajları ve uygulama senaryoları bulunmaktadır.
Bu rehber, Kafka verilerinizi güvence altına almak ve dinamik iş gereksinimlerine yanıt vermek için gerekli temel bilgileri ve pratik adımları sağlamıştır. Her zaman olduğu gibi, herhangi bir üretim ortamı değişikliğinden önce kapsamlı testler yapmak ve iyi bir planlama ile hareket etmek, veri kaybını önlemenin ve sistem sürekliliğini sağlamanın anahtarıdır. Kafka ekosisteminin sürekli geliştiğini unutmayın; bu nedenle, en son araçları ve en iyi uygulamaları takip etmek, veri yönetimi stratejilerinizi güncel tutmanıza yardımcı olacaktır.
