Neden PostgreSQL Veri Dizini Taşımak İsteyesiniz?

Neden PostgreSQL Veri Dizini Taşımak İsteyesiniz?

Ubuntu sunucularında çalışan PostgreSQL veritabanınızın veri dizinini taşımak, ilk bakışta karmaşık gibi görünse de, sistem yöneticileri için hayati öneme sahip bir işlemdir. Bu işlem genellikle disk alanı yetersizliği, performans iyileştirmesi veya yedekleme stratejilerinin optimize edilmesi gibi nedenlerle gündeme gelir. Mevcut disk bölümünüz dolduğunda veya veritabanı performansını artırmak amacıyla daha hızlı bir depolama birimine geçiş yapmak istediğinizde, veri dizinini güvenli bir şekilde yeni bir konuma taşımak kaçınılmaz hale gelebilir. Bu kapsamlı rehber, PostgreSQL veri dizinini Ubuntu üzerinde adım adım nasıl taşıyacağınızı, karşılaşabileceğiniz potansiyel sorunları nasıl aşacağınızı ve en iyi uygulamaları derinlemesine ele alacaktır.

Veritabanı sunucularında, özellikle yüksek trafikli uygulamalar için, disk I/O performansı kritik bir darboğaz olabilir. Örneğin, bir e-ticaret platformu düşünün; artan kullanıcı sayısı ve işlem hacmiyle birlikte veritabanının sürekli olarak diske yazma ve okuma işlemleri yapması, mevcut disk donanımının sınırlarını zorlayabilir. Bu durumda, veri dizinini daha hızlı bir SSD veya NVMe depolama birimine taşımak, sorgu sürelerini önemli ölçüde kısaltabilir ve uygulamanın genel yanıt süresini iyileştirebilir. Ayrıca, bazı durumlarda veri dizinini ayrı bir depolama birimine taşımak, yedekleme ve kurtarma işlemlerini daha esnek hale getirebilir veya güvenlik gereksinimlerini karşılamak için verilerin belirli bir fiziksel konumda saklanmasını sağlayabilir. Bu tür bir taşıma işlemi, planlama ve dikkatli uygulama gerektirse de, uzun vadede sistemin stabilitesi ve performansı için büyük faydalar sunar. Bu rehberde, bu sürecin her aşamasını detaylıca ele alacak, hem yeni başlayanlar hem de deneyimli sistem yöneticileri için değerli bilgiler sunacağız.

PostgreSQL Veri Dizini Nedir ve Neden Önemlidir?

PostgreSQL veri dizini, kısaca PGDATA olarak bilinen, bir PostgreSQL veritabanı kümesinin tüm verilerini ve yapılandırma dosyalarını barındıran ana dizindir. Ubuntu sistemlerinde bu dizin genellikle /var/lib/postgresql/<sürüm>/main gibi bir yolda bulunur (örneğin, /var/lib/postgresql/14/main). Bu dizinin içinde, kullanıcı veritabanları, sistem katalogları, işlem günlükleri (WAL – Write-Ahead Log) dosyaları, yapılandırma dosyaları (postgresql.conf, pg_hba.conf, pg_ident.conf) ve diğer önemli veritabanı nesneleri yer alır. Kısacası, PGDATA dizini, PostgreSQL veritabanınızın kalbidir ve bütünlüğünün korunması, veritabanının sağlıklı çalışması için hayati öneme sahiptir. Bu dizin olmadan PostgreSQL sunucusu başlayamaz veya mevcut verilerine erişemez.

Bu dizinin önemi, sadece verilerin kendisini barındırmasından öte, performans, güvenlik ve kurtarma senaryolarında da kendini gösterir. Örneğin, veri dizininin bulunduğu disk biriminin hızı, veritabanı sorgularının ve yazma işlemlerinin doğrudan performansını etkiler. Yavaş bir disk, yüksek I/O gerektiren işlemlerde darboğaza neden olarak tüm uygulamanın yavaşlamasına yol açabilir. Bu nedenle, PGDATA‘yı daha hızlı bir depolama birimine taşımak, genellikle ciddi performans artışları sağlar. Ayrıca, veri dizininin doğru dosya izinlerine ve sahipliğine sahip olması, veritabanının güvenlik açıklarından korunması için esastır. Yanlış izinler, yetkisiz erişime veya veritabanının başlatılamamasına neden olabilir. Taşıma işlemi sırasında bu detaylara dikkat etmek, veri bütünlüğünü korumak ve olası veri kaybı riskini minimize etmek için kritik öneme sahiptir. PostgreSQL’in sorunsuz çalışması ve verilerinizin güvende olması için PGDATA dizininin yönetimi ve bakımı, her sistem yöneticisinin öncelikli görevlerinden biridir.

Hazırlık Aşaması: Taşımadan Önce Yapılması Gerekenler Nelerdir?

PostgreSQL veri dizini taşıma işlemi, dikkatli bir planlama ve ön hazırlık gerektiren kritik bir operasyondur. Bu aşamada yapılacak yanlışlar, veri kaybına veya uzun süreli kesintilere yol açabilir. Bu nedenle, aşağıdaki adımları titizlikle uygulamanız büyük önem taşır.

Veritabanı Yedeklemesi Almak

Herhangi bir büyük veritabanı operasyonundan önce, mutlaka tam bir yedekleme almalısınız. Bu, olası bir aksilik durumunda verilerinizi kurtarabilmenizi sağlayacak tek güvencenizdir. PostgreSQL için yedekleme yapmanın birkaç yolu vardır:

• Mantıksal Yedekleme (pg_dumpall): Bu yöntem, tüm veritabanı kümelerinizin mantıksal bir yedeğini alır. En güvenli ve esnek yöntemlerden biridir.

    sudo -u postgres pg_dumpall > /yedekler/full_backup_$(date +%Y%m%d%H%M%S).sql
  

• Dosya Sistemi Yedeklemesi (Kopyalama): PostgreSQL hizmetini durdurduktan sonra, mevcut veri dizininin tamamını yeni bir konuma kopyalamaktır. Bu, hızlı bir yedekleme yöntemi olsa da, veritabanı çalışırken yapılmamalıdır.

    sudo rsync -av /var/lib/postgresql/14/main /yedekler/pgdata_backup_$(date +%Y%m%d%H%M%S)
  

Yedekleme dosyasını farklı bir disk bölümünde veya uzak bir depolama alanında sakladığınızdan emin olun.

Disk Alanı Kontrolü ve Hedef Dizin Oluşturma

Yeni veri dizininizi barındıracak hedef disk bölümünde yeterli alan olduğundan emin olun. Mevcut veri dizininizin boyutunu öğrenmek için du -sh komutunu kullanabilirsiniz:

    sudo du -sh /var/lib/postgresql/14/main
  

Yeni disk bölümünüzde uygun bir dizin yapısı oluşturun. Örneğin, /mnt/yeni_disk/postgresql/data gibi bir yol belirleyebilirsiniz. Bu dizini oluştururken mkdir komutunu kullanın:

    sudo mkdir -p /mnt/yeni_disk/postgresql/data
  

Vaka Analizi: Bir finansal teknoloji şirketinin analitik veritabanı, mevcut sunucunun root diskinde yer kalmaması nedeniyle sürekli performans sorunları yaşıyordu. Yeni bir NVMe SSD eklenerek /mnt/nvme_data dizini oluşturuldu. Bu sayede, hem disk alanı genişletildi hem de I/O performansı önemli ölçüde artırıldı. Hazırlık aşamasında, mevcut veritabanının 2 TB boyutunda olduğu tespit edildi ve pg_dumpall ile mantıksal yedekleme alınmasının çok uzun süreceği anlaşıldı. Bu nedenle, dosya sistemi kopyalama yöntemi tercih edildi ve ek olarak anlık bir disk görüntüsü (snapshot) alınarak ek bir güvenlik katmanı oluşturuldu. Bu sayede, taşıma işlemi sırasında olası bir hatada geri dönüş noktası garanti altına alınmış oldu.

PostgreSQL Hizmetini Durdurma

Veri dizinini kopyalamadan veya taşımadan önce PostgreSQL hizmetini tamamen durdurmalısınız. Bu, veri bütünlüğünü sağlamak ve kopyalama sırasında dosya kilitlenmelerini önlemek için kritik bir adımdır:

    sudo systemctl stop postgresql
    sudo systemctl status postgresql
  

status komutu ile hizmetin gerçekten durdurulduğunu doğrulayın. Hizmetin durdurulması, veritabanına olan tüm bağlantıları kesecek ve geçici bir kesinti süresine neden olacaktır. Bu nedenle, bu işlemi genellikle düşük trafikli saatlerde veya planlı bakım pencerelerinde yapmanız önerilir.

PostgreSQL Veri Dizini Adım Adım Nasıl Taşınır?

Hazırlık adımlarını tamamladıktan sonra, PostgreSQL veri dizinini yeni konumuna taşımaya başlayabiliriz. Bu süreç, dikkatli bir şekilde uygulandığında oldukça sorunsuz ilerleyecektir.

Adım 1: PostgreSQL Hizmetini Durdurma

Yukarıda da belirtildiği gibi, taşıma işlemine başlamadan önce PostgreSQL hizmetinin tamamen durdurulması şarttır. Bu, veri tutarsızlıklarını ve olası bozulmaları önler. Hizmeti durdurmak için aşağıdaki komutu kullanın:

    sudo systemctl stop postgresql
  

Hizmetin başarıyla durdurulduğunu doğrulamak için durumunu kontrol edin:

    sudo systemctl status postgresql
  

Çıktıda “Active: inactive (dead)” ifadesini görmelisiniz. Bu, hizmetin kapalı olduğu anlamına gelir. Eğer hizmet hala aktif görünüyorsa, sorun gidermeli ve durdurulduğundan emin olmalısınız.

Adım 2: Mevcut Veri Dizininin Konumunu Bulma

PostgreSQL’in veri dizininin tam konumunu bilmek önemlidir. Varsayılan olarak /var/lib/postgresql/<sürüm>/main olsa da, bu durum sunucu yapılandırmasına göre değişebilir. Mevcut data_directory yolunu öğrenmek için aşağıdaki komutları kullanabilirsiniz:

    sudo -u postgres psql -c "SHOW data_directory;"
  

Bu komut, PostgreSQL’in kendi içinden mevcut veri dizini yolunu döndürecektir. Alternatif olarak, postgresql.conf dosyasını da kontrol edebilirsiniz:

    sudo grep "data_directory" /etc/postgresql/<sürüm>/main/postgresql.conf
  

Bu komutlardan aldığınız yolu, kopyalama işlemi için kullanacaksınız.

Adım 3: Veri Dizini Kopyalama

Mevcut veri dizinini yeni konumuna kopyalamak için rsync komutunu kullanmak en iyi yöntemdir. rsync, dosyaları ve dizinleri kopyalarken izinleri, sahipliği ve zaman damgalarını koruma avantajına sahiptir. Ayrıca, büyük dizinleri kopyalarken ilerleme durumunu gösterir ve kesintiye uğramış bir kopyalamayı sürdürebilir.

    sudo rsync -av /var/lib/postgresql/14/main /mnt/yeni_disk/postgresql/data
  

Burada /var/lib/postgresql/14/main sizin mevcut veri dizininiz, /mnt/yeni_disk/postgresql/data ise daha önce oluşturduğunuz hedef dizindir. Kopyalama işlemi, veritabanınızın boyutuna ve disklerinizin hızına bağlı olarak zaman alabilir. -a (arşiv modu) ve -v (ayrıntılı çıktı) parametreleri, işlemi daha güvenli ve izlenebilir hale getirir. Tüm dosyaların hatasız bir şekilde kopyalandığından emin olmak için rsync çıktısını dikkatlice inceleyin.

Adım 4: PostgreSQL Yapılandırmasını Güncelleme

PostgreSQL’in yeni veri dizini konumunu bilmesi için yapılandırma dosyasını güncellemeniz gerekir. Ana yapılandırma dosyası genellikle /etc/postgresql/<sürüm>/main/postgresql.conf yolundadır. Bu dosyayı bir metin düzenleyici ile açın (örneğin nano veya vim):

    sudo nano /etc/postgresql/14/main/postgresql.conf
  

Dosyanın içinde data_directory parametresini bulun. Genellikle yorum satırı olarak kalır ve varsayılan konum kullanılır. Bu satırı bulup yorum işaretini kaldırın (#) ve yeni dizin yolunu belirtin:

    #------------------------------------------------------------------------------
    # FILE LOCATIONS
    #------------------------------------------------------------------------------

    # The default values of these variables are driven from the -D command-line
    # option or PGDATA environment variable, cf. the file 'backend/utils/misc/postgresql.conf.sample'.

    data_directory = '/mnt/yeni_disk/postgresql/data' # use data in another directory
  

Dosyayı kaydedip kapatın. Bu değişiklik, PostgreSQL’in bir sonraki başlatılışında yeni dizini kullanmasını sağlayacaktır.

Adım 5: Sistemd Hizmet Dosyasını Güncelleme (Opsiyonel ama Önemli)

Ubuntu’da PostgreSQL, systemd tarafından yönetilir. systemd hizmet dosyası, PGDATA ortam değişkenini veya data_directory parametresini doğrudan belirtebilir. Genellikle postgresql.conf dosyasını güncellemek yeterli olsa da, bazı durumlarda (özellikle eski sistemlerde veya özel kurulumlarda) systemd hizmet dosyasında da bir güncelleme gerekebilir. Bu, daha sağlam bir yapılandırma sağlar ve gelecekteki olası sorunları önler. Hizmet dosyasını düzenlemek için aşağıdaki komutu kullanın:

    sudo systemctl edit postgresql@14-main.service
  

Bu komut, /etc/systemd/system/postgresql@14-main.service.d/ dizini altında yeni bir override dosyası oluşturur. Bu dosyaya aşağıdaki içeriği ekleyin:

    [Service]
    Environment=PGDATA=/mnt/yeni_disk/postgresql/data
  

Bu, systemd‘nin PostgreSQL hizmetini başlatırken PGDATA ortam değişkenini belirlediğiniz yeni yola ayarlamasını sağlar. Dosyayı kaydedip kapatın. Ardından systemd yapılandırmasını yeniden yükleyin:

    sudo systemctl daemon-reload
  

Veya, daha basit bir yöntem olarak, eski veri dizininin yerine yeni dizine işaret eden bir sembolik bağlantı (symlink) oluşturabilirsiniz. Bu yöntem daha az yapılandırma değişikliği gerektirir ancak bazı durumlarda performans veya hata ayıklama açısından dezavantajları olabilir:

    sudo mv /var/lib/postgresql/14/main /var/lib/postgresql/14/main_old
    sudo ln -s /mnt/yeni_disk/postgresql/data /var/lib/postgresql/14/main
  

Bu durumda postgresql.conf dosyasında data_directory parametresini değiştirmeye gerek kalmaz, çünkü PostgreSQL hala varsayılan yola bakacak, ancak bu yol sembolik bağlantı aracılığıyla yeni dizini gösterecektir.

Adım 6: Dosya İzinlerini Kontrol Etme

PostgreSQL’in yeni veri dizinine erişebilmesi için doğru dosya izinleri ve sahipliği kritik öneme sahiptir. Veri dizini ve içindeki tüm dosyalar postgres kullanıcısı ve grubuna ait olmalı ve izinler 700 (sadece sahibi okuyabilir, yazabilir ve çalıştırabilir) olmalıdır. rsync genellikle izinleri korusa da, manuel kontrol ve düzeltme yapmak iyi bir uygulamadır:

    sudo chown -R postgres:postgres /mnt/yeni_disk/postgresql/data
    sudo chmod -R 0700 /mnt/yeni_disk/postgresql/data
  

Bu komutlar, yeni veri dizininin sahipliğini postgres kullanıcısına ve grubuna atar ve gerekli izinleri ayarlar. Yanlış izinler, PostgreSQL’in başlatılamamasına veya çalışma zamanı hatalarına neden olabilir.

Adım 7: PostgreSQL Hizmetini Başlatma ve Kontrol Etme

Tüm yapılandırma değişikliklerini ve izin ayarlamalarını yaptıktan sonra, PostgreSQL hizmetini yeniden başlatabilirsiniz:

    sudo systemctl start postgresql
  

Hizmetin başarıyla başlatıldığından emin olmak için durumunu kontrol edin:

    sudo systemctl status postgresql
  

Çıktıda “Active: active (running)” ifadesini görmelisiniz. Ayrıca, PostgreSQL’in yeni veri dizinini kullandığını doğrulamak için psql komutunu kullanın:

    sudo -u postgres psql -c "SHOW data_directory;"
  

Bu komut, yeni dizin yolunu göstermelidir. Herhangi bir hata durumunda, PostgreSQL’in log dosyalarını kontrol etmeyi unutmayın. Log dosyaları genellikle /var/log/postgresql/ dizininde bulunur ve sorun giderme için önemli ipuçları içerir. Örneğin:

    sudo tail -f /var/log/postgresql/postgresql-14-main.log
  

Bu adımları dikkatlice takip ederek, PostgreSQL veri dizininizi Ubuntu üzerinde güvenli ve başarılı bir şekilde taşıyabilirsiniz.

Taşıma Sonrası Optimizasyonlar ve İleri Düzey İpuçları

PostgreSQL veri dizinini yeni bir konuma taşıma işlemi tamamlandığında, işiniz bitmiş sayılmaz. Veritabanı performansını maksimize etmek ve sistemin stabilitesini sağlamak için bazı ek optimizasyonlar ve ileri düzey kontroller yapmanız önemlidir. Bu adımlar, yeni depolama biriminizin potansiyelini tam olarak kullanmanıza ve olası sorunları önceden tespit etmenize yardımcı olacaktır.

Performans İzleme ve Testler

Veri dizinini taşıdıktan sonra, veritabanınızın performansını yakından izlemelisiniz. Yeni depolama biriminin gerçekten beklenen performansı sağlayıp sağlamadığını anlamak için karşılaştırmalı testler yapın. Kullanabileceğiniz araçlar şunlardır:

• pg_stat_statements: PostgreSQL’in yerleşik bir uzantısıdır. En yavaş sorguları ve bunların yürütme sürelerini izlemenizi sağlar.
• iostat veya atop: Sistem düzeyinde disk I/O performansını izlemek için bu Linux araçlarını kullanabilirsiniz. Yeni diskinizin okuma/yazma hızlarını ve gecikme sürelerini gözlemleyin.
• Prometheus ve Grafana: Daha gelişmiş bir izleme çözümü için, PostgreSQL exporter ile Prometheus’tan metrikleri toplayıp Grafana ile görselleştirebilirsiniz. Bu, zaman içindeki performans değişikliklerini izlemek için mükemmel bir yöntemdir.

Eski ve yeni konumlardaki performans verilerini karşılaştırarak, taşıma işleminin beklenen faydaları sağlayıp sağlamadığını değerlendirin. Eğer performans beklentileri karşılamıyorsa, yeni depolama biriminin yapılandırmasını (örneğin, RAID seviyeleri, dosya sistemi seçenekleri) veya PostgreSQL yapılandırmasını (wal_buffers, shared_buffers gibi parametreleri) gözden geçirmeniz gerekebilir.

Eski Veri Dizini ve Güvenlik

Yeni veri dizininin sorunsuz çalıştığından ve tüm verilerin erişilebilir olduğundan emin olduktan sonra bile, eski veri dizinini hemen silmeyin. Bir süre boyunca (örneğin, birkaç gün veya hafta) yedek olarak saklayın. Bu süre zarfında herhangi bir sorun ortaya çıkarsa, eski dizine geri dönme şansınız olur. Eski dizini silmeye karar verdiğinizde, bunu güvenli bir şekilde yapın:

    sudo rm -rf /var/lib/postgresql/14/main_old
  

Bu komutu çalıştırmadan önce, main_old dizininin gerçekten eski ve gereksiz olduğundan emin olun. Ayrıca, sunucu güvenlik duvarı (ufw veya firewalld) ayarlarını kontrol edin. PostgreSQL’in yeni konumda dinlediği portun (varsayılan 5432) hala doğru şekilde açık olduğundan ve dışarıdan erişim kurallarının (pg_hba.conf) geçerli olduğundan emin olun. pg_hba.conf dosyası, veritabanına kimlerin ve nasıl bağlanabileceğini kontrol eden kritik bir güvenlik dosyasıdır; taşıma işlemi bu dosyanın içeriğini etkilemez ancak genel güvenlik kontrolü yapmak her zaman iyidir.

Otomatik Yedekleme ve Kurtarma Komut Dosyalarını Güncelleme

Veri dizininin konumu değiştiği için, mevcut otomatik yedekleme komut dosyalarınızın veya felaket kurtarma planlarınızın güncellenmesi gerekebilir. Örneğin, dosya sistemi düzeyinde yedekleme yapan betikleriniz varsa, bunların yeni PGDATA yolunu işaret ettiğinden emin olun. Mantıksal yedeklemeler (pg_dumpall) genellikle bu tür bir değişiklikten etkilenmez, ancak yedekleme çıktısının kaydedildiği yolu da gözden geçirmek faydalı olacaktır. Ayrıca, bir felaket durumunda veritabanını kurtarma adımlarını içeren dokümanlarınızı da güncellemeyi unutmayın. Mobil uyumluluk açısından, bu tür kritik sistem yönetim görevleri için geliştirilen araçların veya kontrol panellerinin @media screen and (max-width: 768px) gibi CSS kurallarıyla mobil ekranlara uyumlu olması, yöneticilerin her an her yerden sisteme erişim ve izleme yapabilmesi için önemlidir.

Sembolik Bağlantı (Symlink) Kullanımı ve Riskleri

Bazı yöneticiler, postgresql.conf dosyasını düzenlemek yerine eski veri dizini yoluna yeni dizini gösteren bir sembolik bağlantı oluşturmayı tercih edebilir. Bu yöntem, yapılandırma değişikliği miktarını azaltır ve daha hızlı bir çözüm gibi görünebilir. Ancak, sembolik bağlantıların bazı dezavantajları ve riskleri vardır:

• Karmaşıklık: Özellikle karmaşık dosya sistemlerinde veya birden fazla PostgreSQL kümesi yönetirken, sembolik bağlantılar takip edilmesi zor olabilir ve hata ayıklamayı zorlaştırabilir.
• Sistemd Etkileşimi: systemd gibi hizmet yöneticileri, bazen sembolik bağlantılarla ilgili beklenmedik davranışlar sergileyebilir. Doğrudan PGDATA ortam değişkenini veya data_directory parametresini ayarlamak genellikle daha şeffaf ve güvenilir bir yöntemdir.
• Performans: Çoğu modern dosya sisteminde sembolik bağlantılar performans üzerinde ihmal edilebilir bir etkiye sahip olsa da, aşırı kullanım veya belirli senaryolarda küçük bir ek yük getirebilir.

Bu nedenle, mümkün olduğunca postgresql.conf dosyasındaki data_directory parametresini doğrudan güncellemek veya systemd override dosyası kullanmak daha iyi bir uygulama olarak kabul edilir. Sembolik bağlantılar, hızlı testler veya geçici çözümler için uygun olabilir, ancak uzun vadeli, üretim ortamlarında dikkatli kullanılmalıdır.

Bu ileri düzey ipuçları ve optimizasyonlar, PostgreSQL veri dizini taşıma işleminizin sadece teknik olarak başarılı olmasını değil, aynı zamanda operasyonel olarak da sağlam ve performanslı olmasını sağlayacaktır. Unutmayın, sistem yönetimi sadece bir işlemi tamamlamak değil, aynı zamanda sistemin uzun vadeli sağlığını ve güvenliğini sağlamaktır.

Vaka Analizi: Yüksek Trafikli Bir Web Uygulamasının Veri Dizini Taşıma Deneyimi

Bir e-ticaret platformu olan “TrendyShop”, artan müşteri trafiği ve ürün katalogları nedeniyle veritabanı performansında ciddi düşüşler yaşamaya başlamıştı. Mevcut sunucularında PostgreSQL veritabanı, işletim sisteminin kurulu olduğu aynı standart HDD üzerinde çalışıyordu. Özellikle kampanya dönemlerinde ve yoğun alışveriş saatlerinde, web sitesi yanıt süreleri uzuyor, sepet işlemleri yavaşlıyor ve genel kullanıcı deneyimi olumsuz etkileniyordu. Sistem yöneticileri, performans izleme araçları (Prometheus ve Grafana) kullanarak disk I/O değerlerinin sürekli olarak %90’ın üzerinde seyrettiğini ve CPU kullanımının nispeten düşük olmasına rağmen veritabanı sorgularının kuyrukta beklediğini tespit ettiler. Bu durum, açıkça bir disk I/O darboğazına işaret ediyordu.

Sorun Tespiti: TrendyShop’un PostgreSQL veritabanı (/var/lib/postgresql/14/main), saniyede yüzlerce okuma/yazma işlemi gerçekleştiren bir e-ticaret uygulamasının yükünü kaldıramıyordu. Mevcut disk, saniyede ortalama 150-200 IOPS (Input/Output Operations Per Second) sunarken, uygulamanın anlık olarak 500-600 IOPS’ye ihtiyaç duyduğu gözlemlendi. Bu yetersizlik, veritabanının diskten veri okuma ve yazma hızını sınırlıyor, dolayısıyla sorguların tamamlanma süresini uzatıyordu.

Çözüm: Sistem yöneticileri, mevcut sunucuya iki adet yüksek performanslı NVMe SSD diski eklemeye karar verdiler. Bu diskler, RAID 1 (mirroring) yapılandırmasında birleştirilerek hem yüksek IOPS kapasitesi (yaklaşık 10.000-20.000 IOPS) hem de veri yedekliliği sağlandı. PostgreSQL veri dizini, bu yeni ve hızlı depolama birimine taşınacaktı. Hedef dizin /mnt/nvme_data/postgresql/data olarak belirlendi.

Uygulanan Adımlar ve Karşılaşılan Zorluklar:

1. Planlama ve Kesinti Süresi Yönetimi: TrendyShop, 7/24 hizmet veren bir platform olduğundan, kesinti süresini minimumda tutmak kritikti. Taşıma işlemi, en düşük trafikli gece saatlerine (03:00-05:00 arası) planlandı. Müşterilere önceden bilgilendirme yapıldı.
2. Yedekleme: Taşıma işleminden hemen önce, 2 TB boyutundaki veritabanının tam bir pg_dumpall yedeği alındı. Ayrıca, mevcut veri dizininin /var/lib/postgresql/14/main_old olarak hızlı bir şekilde kopyası oluşturuldu. Bu, herhangi bir sorun yaşanması durumunda anında geri dönüş imkanı sağladı.
3. PostgreSQL Hizmetini Durdurma: Planlanan saatte sudo systemctl stop postgresql komutuyla hizmet durduruldu.
4. Veri Kopyalama: rsync komutu, veri dizinini yeni NVMe disklere kopyalamak için kullanıldı:

   
           sudo rsync -av /var/lib/postgresql/14/main /mnt/nvme_data/postgresql/data
         

   Bu işlem, 2 TB’lık veri için yaklaşık 45 dakika sürdü. rsync‘in ilerleme göstergesi sayesinde, yöneticiler sürecin ne kadar kaldığını takip edebildi.

5. Yapılandırma Güncellemesi: /etc/postgresql/14/main/postgresql.conf dosyası düzenlenerek data_directory parametresi /mnt/nvme_data/postgresql/data olarak güncellendi.
6. İzin Ayarları: Yeni dizin ve içeriği için sudo chown -R postgres:postgres /mnt/nvme_data/postgresql/data ve sudo chmod -R 0700 /mnt/nvme_data/postgresql/data komutları çalıştırılarak doğru izinler sağlandı.
7. Hizmeti Başlatma ve Kontrol: PostgreSQL hizmeti sudo systemctl start postgresql ile başlatıldı ve psql -c "SHOW data_directory;" ile yeni konum doğrulandı. Log dosyaları (/var/log/postgresql/postgresql-14-main.log) kontrol edilerek herhangi bir hata olup olmadığına bakıldı.

Elde Edilen Kazançlar: Taşıma işlemi başarıyla tamamlandıktan sonra, TrendyShop platformunda anında bir performans artışı gözlemlendi. Disk I/O darboğazı tamamen ortadan kalktı. Sorgu süreleri ortalama %70 oranında kısaldı. Web sitesi yanıt süreleri 500 ms’den 150 ms’ye düştü. Özellikle kampanya dönemlerindeki yoğunlukta bile sistemin stabil çalıştığı ve kullanıcı deneyiminin önemli ölçüde iyileştiği görüldü. Bu vaka analizi, doğru planlama ve hızlı depolama çözümleriyle veri dizini taşımanın, yüksek trafikli uygulamalar için ne kadar kritik bir performans iyileştirmesi sağlayabileceğini açıkça göstermektedir. Bu tür operasyonları planlarken, mobil cihazlardan izleme ve yönetme kolaylığı için responsive tasarıma sahip araçlar kullanmak önemlidir. Örneğin, yönetim panelleri veya log görüntüleyiciler, @media screen and (max-width: 768px) gibi CSS kurallarıyla mobil ekranlara uyum sağlayabilir, böylece yöneticiler acil durumlarda bile hızlıca müdahale edebilirler.

Sonuç

PostgreSQL veri dizinini Ubuntu üzerinde taşımak, dikkat ve özen gerektiren ancak doğru adımlar izlendiğinde oldukça yönetilebilir bir işlemdir. Bu kapsamlı rehberde ele aldığımız gibi, taşıma işlemi genellikle disk alanı yetersizliği, performans iyileştirmesi veya daha iyi yedekleme stratejileri gibi önemli operasyonel ihtiyaçlardan doğar. Başarılı bir taşıma süreci, titiz bir hazırlık aşaması (yedekleme, hedef dizin oluşturma), adım adım veri kopyalama ve yapılandırma güncellemeleri, doğru izin ayarları ve taşıma sonrası kapsamlı testler ile mümkündür. Unutulmamalıdır ki, veri bütünlüğü ve sistem güvenliği her zaman en öncelikli konulardır. Bu nedenle, her adımın doğru bir şekilde uygulandığından ve olası risklerin minimize edildiğinden emin olmak için dikkatli olmak esastır. Veritabanı performansını artırmak ve sisteminizin uzun vadeli sağlığını güvence altına almak için bu tür operasyonları doğru bir şekilde gerçekleştirmek, her sistem yöneticisinin yetkinlikleri arasında yer almalıdır. Bu rehberin, PostgreSQL veri dizini taşıma sürecini anlamanıza ve başarılı bir şekilde uygulamanıza yardımcı olmasını umuyoruz.

Sıkça Sorulan Sorular

S1: Taşıma sırasında veri kaybı riski var mı?

C1: Evet, eğer yedekleme yapmazsanız veya adımları yanlış uygularsanız veri kaybı riski vardır. Ancak, bu rehberde belirtilen tüm adımları (özellikle yedekleme) dikkatlice takip ederseniz, veri kaybı riski minimuma iner.

S2: Taşıma işlemi ne kadar sürer?

C2: Taşıma süresi, veritabanınızın boyutuna, mevcut ve hedef disklerinizin hızına bağlıdır. Küçük bir veritabanı birkaç dakika sürerken, terabaytlarca veri içeren bir veritabanı saatler sürebilir. rsync komutunun ilerleme göstergesi, tahmini süreyi anlamanıza yardımcı olacaktır.

S3: Eski veri dizinini ne zaman silebiliriz?

C3: Yeni veri dizininin sorunsuz çalıştığından ve veritabanı uygulamanızın beklendiği gibi çalıştığından emin olduktan sonra, eski dizini silebilirsiniz. Genellikle, yeni kurulumu birkaç gün veya bir hafta boyunca gözlemlemek iyi bir uygulamadır. Güvenli olduğunuzdan emin olana kadar eski dizini bir yedek olarak saklayın.

S4: Sembolik bağlantı (symlink) kullanmak iyi bir fikir mi?

C4: Sembolik bağlantılar, hızlı ve geçici çözümler için uygun olabilir. Ancak, üretim ortamlarında genellikle postgresql.conf dosyasındaki data_directory parametresini doğrudan güncellemek veya systemd override dosyası kullanmak daha güvenilir ve şeffaf bir yöntemdir. Symlinkler, hata ayıklamayı zorlaştırabilir ve beklenmedik davranışlara yol açabilir.

S5: PostgreSQL’in farklı sürümleri arasında veri dizini taşıyabilir miyim?

C5: Hayır, PostgreSQL’in farklı ana sürümleri arasında veri dizinini doğrudan taşıyamazsınız. Her ana sürümün kendi veri formatı ve dizin yapısı vardır. Sürüm yükseltmeleri için pg_upgrade gibi özel araçları veya mantıksal yedekleme/geri yükleme (pg_dumpall/psql) yöntemlerini kullanmanız gerekir. Bu rehber, aynı PostgreSQL sürümü içinde veri dizini konumunu değiştirmeyi amaçlamaktadır.