pg_dump İle Yedekleme ve Geri Yükleme İşlemleri

pg_dump Postgresql veritabanını yedeklemek için kullanılan programdır.

  • pg_dump tarafından alınan dump dosyaları tamamen tutarlıdır, çünkü dump, veritabanınızın ve pg_dump’ın çalışmaya başladığı andaki verilerinin anlık görüntüsüdür(snapshot).
  • pg_dump diğer kullanıcıların veritabanına (read veya write) erişimini engellemez.
  • pg_dump kullanmak için özel bir yetki gerekmez; Normal bir kullanıcı bile, kullanıcının belirli bir veritabanı üzerinde izni olması koşuluyla onu çalıştırabilir.

pg_dump yalnızca tek bir veritabanının yedeğini alır. Clusterın tamamını yedeklemek veya clusterdaki tüm veritabanlarında ortak olan genel nesneleri (roller ve tablespace gibi) yedeklemek için pg_dumpall kullanılır.

Dump dosyaları, komut veya arşiv dosyası formatlarında çıkarılabilir. Komut dosyasında oluşan dump dosyası, veritabanını kaydedildiği sırada bulunduğu duruma yeniden yapılandırmak için gereken SQL komutlarını içeren düz metin dosyalarıdır. Böyle oluşan komut dosyasını geri yüklemek için oluşan sql dosyasını psql veya başka bir araç ile çalıştırmamız yeterlidir. Bu komut çalıştırılırken psql’de veritabanı ismi ile verilen veri tabanı yaratılmış olmalıdır, aksi halde objeler varsayılan olarak gelen postgres veritabanında yaratılır. Kullanım kolaylığı nedeni ile mimari ve makine değişimlerinde  veritabanını yeniden yapılandırmak için kullanılabilir.

Veritabanını elle oluşturmak istemiyorsak pg_dump ile arşiv dosyası formatında (custom, directory, tar) yedekler almalıyız ancak bu durumda restore işlemini psql yerine pg_restore aracı ile yapmalıyız. pg_restore’un neyin geri yüklendiği konusunda seçici olmasını ve hatta öğeleri geri yüklenmeden önce yeniden düzenlemesinide sağlar, bu şekilde daha esnek bir yöntem elde etmiş oluruz. Arşiv dosyası formatları, mimariler arasında taşınabilir olacak şekilde tasarlanmıştır. pg_dump komutunun sintaksı aşağıdaki gibidir;

pg_dump [connection-option…] [option…] [dbname]

Hangi sunucu üzerindeki veri tabanlarını yedeklemek istiyorsak, -h host ve -p port komutlarını kullanarak bunu belirtebiliriz. Varsayılan sunucu, lokal sunucudur ya da PGHOST değişkeninde ne belirtildiyse odur. Aynı şekilde, varsayılan portun değeri de PGPORT değişkeninde belirtilen değerdir ya da derlenmiş olan varsayılan değeri alır. Diğer PostgreSQL istemci uygulmaları gibi, pg_dump varsayılan olarak, geçerli işletim sistemi adına eşit olan veri tabanı kullanıcı adına bağlanacaktır. Bunu ezmek için, ya -U seçeneğini ya da PGUSER değişkenini kullanabiliriz.

Örnekler; (devamı..)

Loading


PostgreSQL Copy Komutu

COPY, verileri PostgreSQL tabloları ve standart dosya sistemi dosyaları arasında taşır. COPY TO tablonun içeriğini dosyaya kopyalarken, COPY FROM dosyadaki verileri tabloya kopyalar. COPY TO ayrıca SELECT sorgusunun sonuçlarınıda kopyalayabilir yani sütun listesi belirtilirse COPY TO yalnızca belirtilen sütunlardaki verileri dosyaya kopyalar. COPY FROM için, dosyadaki her alan sırayla belirtilen sütuna eklenir. COPY FROM sütun listesinde belirtilmeyen tablo sütunları, varsayılan değerlerini alır.

  • COPY komutu PostgreSQL sunucusuna doğrudan dosyadan okuma veya dosyaya yazma talimatı verir bu nedenle dosya, PostgreSQL kullanıcısı tarafından erişilebilir olmalı.
  • COPY TO tarafından okunan tablo üzerinde SELECT ve COPY FROM ile değerlerin eklendiği tabldaa INSERT yetkilerinin olması gerekir.
  • COPY TO yalnızca tablolarla kullanılabilir, viewlerde kullanılamaz. Bununla birlikte viewin içeriğini kopyalamak istersek COPY komutunu sql sorgusu ile beslemeliyiz( COPY (SELECT * FROM country) TO ‘list_countries.copy’;).
  • COPY komutunda adlandırılan dosyalar, client uygulaması tarafından değil, doğrudan sunucu tarafından okunur veya yazılır. Bu nedenle, client da değil, veritabanı sunucusu makinesinde bulunmalı veya bu makine tarafından erişilebilir olmalıdır.
  • COPY ile psql’deki \copy’yi karıştırmamalıyız. \copy, COPY FROM STDIN veya COPY TO STDOUT’u çağırır ve ardından verileri psql client tarafından erişilebilen bir dosyada alır ve depolar. Bu nedenle, dosya erişilebilirliği ve erişim hakları, \ opy kullanıldığında sunucudan çok cliente bağlıdır.

Örnekler; (devamı..)

Loading


PostgreSQL’de Parametreler ve Konfigurasyon Dosyası (postgresql.conf ve postgresql.auto.conf)

Konfigurasyon dosyası temel olarak instance’ın davranışını etkiler, örneğin izin verilen bağlantı sayısı, veritabanı log yönetimi, vaccum, wal parametrelerini belirleme vb. Elbette tüm bunlar, veritabanı kurulduğunda varsayılan bir değere sahiptir, ancak bu değerleri iş yükünü ve çalışma ortamını daha iyi yansıtacak şekilde değiştirebiliriz.

Bu parametreleri ayarlamanın en temel yolu, normalde $PGDATA dizininde tutulan postgresql.conf dosyasını düzenlemektir, postgresql.conf dosyası init aşamasında varsayılan olarak kopyası yüklenir. Eğer postgresql.conf dosyasının tam yolunu komut kullanarak bulmak istersek aşağıdaki komutu kullanıyoruz.

select * from pg_settings where name='config_file';

Örnek bir postgresql.conf dosyası aşağıdaki gibidir, tahmin edileceği üzere her satıra bir parametre belirtilir,  name ve value arasındaki eşittir işareti opsiyoneldir. boşluklar önemsiz, # işareti ise satırın geri kalanını yorum olarak belirler.

Postgresql Parameter

NOT : posgresql.conf dosyasında aynı parametre için birden çok girdi içeriyorsa, sonuncusu hariç tümü yok sayılır, yani dosyada en son yazar değer geçerli olur.

Bu şekilde ayarlanan parametreler, cluster için varsayılan değerleri sağlar, aktif sessionlar tarafından görülen ayarlar, geçersiz kılınmadıkları sürece bu değerler olacaktır.

Postgresql main prosesi SIGHUP sinyalini aldığı zaman Postgresql konfigürasyon dosyası yeniden okunur. Bu sinyal postgresql’e iki yolla gönderilebilir. İşletim sistemi üzerinde postgres kulanıcısı ile “pg_ctl reload” komutu ile veya psql komut satırı aracından “SELECT pg_reload_conf()” komutu ile postgresql.conf dosyasının tekrar okunması sağlanır. Main prosesi ayrıca bu sinyali şu anda çalışan tüm sunucu proseslerine yayar, böylece mevcut sessionlar da yeni değerleri benimser (bu, o anda yürütülen herhangi bir client komutunu tamamladıktan sonra gerçekleşir). Alternatif olarak, sinyali doğrudan tek bir sunucu işlemine gönderebilirsiniz.  Konfigurasyon dosyasındaki geçersiz parametre ayarları benzer şekilde SIGHUP işlemi sırasında göz ardı edilir (ancak loga kaydedilir).

-bash-4.2$ /usr/pgsql-12/bin/pg_ctl reload
server signaled
-bash-4.2$ psql
psql (12.4)
Type "help" for help.

postgres=# select pg_reload_conf();
 pg_reload_conf 
----------------
 t
(1 row)

Bazı parametreler yalnızca sunucu başlangıcında ayarlanabilir; bu parametreleri için postgresql.conf dosyasının yorum kısmında “# (change requires restart)” yazar.

Postgresql.conf’a ek olarak, postgresql.conf ile aynı biçime sahip olan ancak manuel olarak değil, otomatik olarak düzenlenmesi amaçlanan bir postgresql.auto.conf dosyası içerir. Bu dosya, ALTER SYSTEM komutu ile sağlanan ayarları içerir. postgresql.auto.conf içindeki ayarlar postgresql.conf içindekileri geçersiz kılar. postgresql.auto.conf dosyasıda $PGDATA dizininde bulunur.

NOT : Pg_settings system viewi, sunucunun çalışma zamanı parametrelerine erişim sağlar. Esasen SHOW ve SET komutlarına alternatif bir arayüzdür. Ayrıca, minimum ve maksimum değerler gibi, SHOW’da doğrudan bulunmayan her parametre hakkında bazı gerçeklere erişim sağlar.

 select * from setting where name  = 'configuration_parameter';
UPDATE pg_settings SET setting = reset_val WHERE name = 'configuration_parameter';

Parametrelerin SQL ile Değiştirilmesi

PostgreSQL, parametreleri düzenlemek için üç SQL komutu sağlar.

  • ALTER SYSTEM : Cluster seviyesindeki parameterleri değiştirmek için kullanılır, postgresql.conf’u düzenlemeye eşdeğerdir. Bu parametre ile yapılan değişiklerin postgresql.auto.conf dosyasına yazıldığını söylemiştik. Örnekler;
ALTER SYSTEM SET wal_level = replica;
ALTER DATABASE test SET timezone = 'UTC-5';
ALTER SYSTEM RESET wal_level;
ALTER SYSTEM RESET ALL; 
  • ALTER DATABASE : Global parametrelerin veri tabanı bazında override edilmesi sağlanır. Örnekler;
 ALTER DATABASE db_test SET escape_string_warning = off;
ALTER DATABASE db_test SET enable_indexscan TO off;
ALTER DATABASE test SET timezone = 'UTC-5';
ALTER DATABASE db_test RESET escape_string_warning;
ALTER DATABASE db_test RESET ALL;
  • ALTER ROLE : Kullanıcıya özel parametre geçilmesini sağlar. Örnekler;
 ALTER ROLE test_user SET client_min_messages  = DEBUG;
ALTER ROLE test_user SET maintenance_work_mem = 100000;
ALTER ROLE test_user IN DATABASE test_db SET maintenance_work_mem = 100000;
ALTER USER test_user IN DATABASE test_db RESET maintenance_work_mem;
ALTER USER test_user IN DATABASE test_db RESET ALL;
ALTER USER test_user IN DATABASE test_db SET timezone = 'UTC-7';

(devamı..)

Loading


PostgreSQL Kimlik Doğrulama Ayarları – pg_hba.conf Dosyası

Client kimlik doğrulaması (authentication ), pg_hba.conf olarak adlandırılan ve $PGDATA’da depolanan bir yapılandırma dosyası tarafından kontrol edilir. (HBA, host-based authentication anlamına gelir.) pg_hba.conf dosyası varsayılan olarak initdb aşamasında $PGDATA dizininde oluşturulduğunu söyledik eğer istersek  hba_file parametresi ile başka bir dizinde belirtebiliriz.

Dosyada ki her kayıt bağlantı tipi, client ip adres aralığı(bağlantı tipi için uygunsa), veritabanı adı, kullanıcı adı ve bu parametrelerle eşleşen kimlik doğrulama(authentication) yöntemini belirtir. Dosyadaki kayıtlar aşağıdaki örnekler gibi birkaç farklı biçimde olabilir.

 local         database  user  auth-method [auth-options]
host          database  user  address     auth-method  [auth-options]
hostssl       database  user  address     auth-method  [auth-options]
hostnossl     database  user  address     auth-method  [auth-options]
hostgssenc    database  user  address     auth-method  [auth-options]
hostnogssenc  database  user  address     auth-method  [auth-options]
host          database  user  IP-address  IP-mask      auth-method  [auth-options]
hostssl       database  user  IP-address  IP-mask      auth-method  [auth-options]
hostnossl     database  user  IP-address  IP-mask      auth-method  [auth-options]
hostgssenc    database  user  IP-address  IP-mask      auth-method  [auth-options]
hostnogssenc  database  user  IP-address  IP-mask      auth-method  [auth-options]
  • local : Bu kayıt, Unix domain soketleri kullanan bağlantı girişimleriyle eşleşir. Bu tür bir kayıt olmadan, Unix domain soket bağlantılarına izin verilmez dolayısıyla localhost’dan gelen isteklerde başarısız olur.
  • host : TCP/IP protokolü ile veri tabanına bağlantı kurmak isteyen clientlar için kural tanımlamayı sağlar.
  • hostssl : TCP/IP protokolü kullanılarak sadece SSL bağlantı taleplerine karşılık vermek için kullanılan tanımlamadır. Bu seçeneği kullanmak için sunucu SSL desteği ile oluşturulmalıdır. SSL yapılandırma parametresi ayarlanarak etkinleştirilmelidir. Aksi takdirde, hostssl kaydı, herhangi bir bağlantıyla eşleşemeyeceğine dair bir uyarı loga yazılması dışında yok sayılır.
  • hostnossl : SSL kullanmadan sadece TCP/IP üzerinden gelen bağlantı taleplerini karşılamak için kullanılan tanımlamadır.
  • hostgssenc : Bu kayıt, TCP / IP kullanılarak yapılan bağlantı girişimleriyle eşleşir, ancak yalnızca bağlantı GSSAPI şifrelemesiyle yapıldığında gerçekleşir. Bu seçenekten yararlanmak için sunucu GSSAPI desteği ile oluşturulmalıdır. GSSAPI şifrelemesiyle kullanılmak üzere desteklenen authentication yöntemlerinin gss, reject ve trust olduğunuda bilmeliyiz.
  • hostnogssenc : Bu kayıt türü, hostgssenc’in ters davranışına sahiptir; yalnızca GSSAPI şifrelemesini kullanmayan TCP / IP üzerinden yapılan bağlantı girişimleriyle eşleşir.

NOT : Sunucu, listen_addresses yapılandırma parametresi için uygun bir değerle başlatılmadıkça TCP / IP bağlantıları mümkün olmayacaktır, çünkü varsayılan davranış TCP / IP bağlantılarını yalnızca local loopback adresinde localhost’da dinlemektir. (devamı..)

Loading


PostgreSQL Replikasyonda Switchover

Switchover, Primary ve Standby sunucularımızın rollerini değiştirmesi işlemidir. Switchover işlemi primary sunucusuna bakım gereksiniminden dolayı olabileceği gibi veritabanınızın çalıştığı sunucuyu en az kesinti ile değiştirmek için de kullanılabilir.

PostgreSQL, primary’deki bir arızayı tanımlamak ve standby veritabanı sunucusunu bilgilendirmek için gerekli olan sistem yazılımını sağlamaz. Farklı yüksek erişilebilirlik çözümleri bu işlemleri sizin için otomatik yapabileceği gibi bu işlemi elle de gerçekleştirebilirsiniz. Birçok yük devretme sistemi, ikisi arasındaki bağlantıyı ve primary sunucunun kullanılabilirliğini sürekli olarak doğrulamak için bir tür heartbeat mekanizması kullanır veya gereksiz yük devretme durumlarını önlemek için üçüncü bir sistem (witness server olarak da adlandırılır) kullanmak da mümkündür, ancak yeterli özen ve titiz testlerle kurulmadıkça yapıyı karmaşıklaştırmak kaş yapayım derken göz çıkarma gibi bir şey olur. (Sonunda bir deyimi tam yerinde kullanabildim 🙂 )

Standby’ı yeni primary olarak tanıtmanın iki yolu vardır. Switchover, değişimin planlı bir şekilde gerçekleşmesidir. Biz bu yazımızda switchover işlemini manuel yapacağız; Kabaca aşağıdaki adımların işletilmesi ile rol değiştirme işlemi gerçekleştirilebilir.

  1. Veritabanına yeni veri gelmesini engelemmek için tüm client bağlantıları kesilir.
  2. WAL kayıtlarının standby lara aktarılması beklenip, onaylanır.
  3. Primary sucunu temiz bir şekilde kapatılır.
  4. Standby sunucu kontrol edilerek primary haline getirilir.
  5. Eski primary sunucusu uygun yapılandırma ile Stanby olarak açılır.

Adımlar doğru bir şekilde gerçekleştirilmediği taktirde eski Primary sunucusu yeni Primary’e Standby olarak bağlanamayacaktır. Bu durumda replikasyonu yeniden başlatabilmek için yedekten dönmemiz gerekebilir yada aradaki farkı bulup işlemek için pg_rewind aracından yararlanabiliriz.

pg_rewind : pg_rewind, 9.5 sürümünden beri bir PostgreSQL aracıdır. Özellikle pg_rewind büyük veritabanları için avantaj sağlar. Veritabanlarını pg_basebackup kullanmadan senkronize edebilirsiniz. pg_rewind, eski primary veritabanının pgdata klasörünü tarar ve standby sunucusuna geçiş sırasında değiştirilen veri bloklarını tanımlar, ardından yalnızca ilişki dosyalarından değiştirilen blokları kopyalar; diğer tüm dosyalar, yükseltilmiş standby sunucudaki yapılandırma dosyaları dahil tam olarak kopyalanır. Ve eski primary veritabanı, değiştirilen blokların uygulanmasıyla senkronize olur. pg_rewind, hedef sunucunun postgresql.conf içinde wal_log_hints seçeneğinin etkinleştirilmesini veya veritabanı initdb ile başlatıldığında checksums etkinleştirilmesini gerektirir. full_page_writes da açık olarak ayarlanmalıdır, ancak varsayılan olarak etkindir. (devamı..)

Loading


PostgreSQL’de Logical Replikasyon

Logical replikasyon, veri objelrini ve değişikliklerini replikasyon kimliklerine(replication identity) (genellikle primary key olur) dayalı olarak replikasyon yöntemidir. Bir önceki yazımda detaylı şekilde anlattığım gibi stream replikasyon,  primary sunucudaki her değişiklik WAL üzerinden stream edilip, standby sunucuya uygulanır. Bununla birlikte, stream replikasyon kullanırken bazı şeyler mümkün değildir;

  • Stream replikasyon cluster seviyesindedir, cluster da sadece istediğimiz veritabanları veya veritabanlarındaki istediğimiz objeleri replikasyon yapamayız. Stream replikasyonla sadece komple cluster seviyesinde replikasyon yapabiliriz, tahmin edeleceği gibi bu kısıtın nedeni de cluster seviyesinde sadece bir tane WAL mekanizması olması.
  • Stream replikasyonla iki majör versiyon arasında replikasyon yapılamaz.
  • Standby sunucu read-write olarak kullanılmaz.
  • Farklı platformlar arasında replikasyon yapılamaz.(Linux,Windows vb.)
  • Birden fazla veritabanını aynı yere replikasyon yapılamaz.

PostgreSQL 10 ile stream replikasyonun yukarıdaki sınırlamalarını ele alan ve replikasyonda yeni kullanım alanları yaratan logical replikasyon hayatımıza girdi. Transactional replikasyon olarak da bilinir.

Logical replikasyon, publish ve subscribe modelini takip eder. Publisher(kaynak) sunucu, bir tablodan veya bir grup tablodan yapılan değişikliklerden oluşan bir publication(yayın) oluşturulur. Subscriber sunucu, bir veya daha fazla publication(yayına) abone olabilen bir abonelik oluşturulur. Publication, triggerların belirli olay türleri tarafından nasıl çalıştırıldığına benzer şekilde, ürettikleri değişiklikleri herhangi INSERT, UPDATE, DELETE ve TRUNCATE kombinasyonuyla sınırlamayı seçebilirler. Varsayılan olarak, tüm işlem türleri çoğaltılır.

postgresql logical replication

Update veya delete görecek satırların abone tarafında tanımlanabilmesi için, yayınlanan bir tablonun GÜNCELLEME ve SİLME işlemlerini replike edebilmek için yapılandırılmış bir replica identity olması gerekir. Varsayılan olarak bu primary key’dir, tabi istenirse unique bir sütunda replica identity olarak seçilebilir. Tablonun primary key veya uniqe alanı yoksa bu defada replica identity olarak full seçebiliriz yani tüm satırı replica identity olarak kullanabiliriz, ancak bu  çok verimsizdir. Publisher tarafında “full” dışında bir replica identity ayarlanmışsa, subscriber tarafında aynı veya daha az sütunu içeren bir replica identity de ayarlanmalıdır.Bu arada her publication’ın birden fazla subscriber’ı olabilir. Kaynak ve hedefteki tablolar farklı sütun sayısına veya sırasına sahip olabilir ancak sütun veri tipleri ve sütun adları aynı olmalıdır.

Her subscription, değişiklikleri bir replication slot aracılığıyla alacaktır. Subscription silindiğinde ve yeniden oluşturulduğunda, senkronizasyon bilgileri kaybolur. Bu, verilerin daha sonra yeniden senkronize edilmesi gerektiği anlamına gelir. Şema tanımları kopyalanmaz ve yayınlanan tablolar abone üzerinde bulunmalıdır. Yalnızca normal tablolar çoğaltmanın hedefi olabilir. Yani aşağıdaki objeleri logical replikasyona dahil edemeyiz;

  • Veritabanı şemaları ve DDL komutları replike edilemez, şema pg_dump –schema-only kullanılarak elle kopyalanabilir. Sonraki şema değişikliklerinin manuel olarak senkronize edilmesi gerekir. Bununla birlikte, şemaların her iki tarafta da kesinlikle aynı olmasına gerek olmadığını unutmayın taki bizim subscriber sunucuya gelen tablolarımızla ilgili değişiklik yapmadığımız sürece.
  • Sequence replikasyonu yapılamaz, subscriber read only bir veritabanı olarak kullanılıyorsa, bu genellikle bir sorun teşkil etmemelidir. Bununla birlikte, subscriber veritabanına bir tür geçiş veya yük devretme amaçlanıyorsa, publisher’dan mevcut verileri kopyalayarak (pg_dump kullanarak) veya yeterince yüksek bir değer belirleyerek sequenclerin en son değerlere güncellenmesi gerekecektir.
  • Large nesneler replike edilemez
  • View ve Materialized view replike edilemez
  • Foreing table replike edilemez
  • Partition tablolardaki root bölümler replike edilemez

Şimdi Örnek üzerinden bir logical replikasyon yapılandıralım; (devamı..)

Loading


  • Sertifikasyon



  • Etiketler

  • Topluluklar

                     
                     
  • Copyright © 1996-2010 Mustafa Bektaş Tepe. All rights reserved.
    Türkçeleştirme Blogizma | AltyapıWordPress