Skip to main content

pg_upgrade ile PostgreSQL Sürüm Güncellemesi

Merhaba,

PostgreSQL sunucusunun da gelen yeni özellikleri kullanabilmek ve geliştirmeleri sıkı takip ederken kendi sistemimize entegre etmemiz önemli. Şu an PostgreSQL'in en güncel versiyonu 10. PostgreSQL 11 beta test edilmeye çoktan başlandı. Dolayısıyla eğer PostgreSQL sunucunuzun versiyonu 9.6 ve altındaysa 10'a geçirmeyi planlıyorsanız bunu pg_upgrade aracını kullanarak yapabilrsiniz.

Major geçişten kasıt 9.6'dan 10'a geçilmesi burada. Böyle bir değişiklik yapmadan önce konfigürasyon dosyalarının yedeğinin alınmasını tavsiye ediyoruz. 

pg_upgrade komutunun kullanımı şöyledir.

pg_upgrade -d <eski_data_dizini> -D <yeni_data_dizini> -b <eski_bin_dizini> -B <yeni_bin_dizini> [Diğer_Seçenekler]

Diğer seçenekler aşağıdaki gibidir. Bunları kullanarak da ilerleyebilirsiniz.

-b, --old-bindir=Eski bin dizini gösterir.
-B, --new-bindir=Yeni bin dizinini gösterir.
-c, --check=iki cluster arasında pg_upgrade komutunun başarılı çalışıp çalışmadığını kontrol etmemizi sağlar.
-d, --old-datadir=Eski datadir dizinini göstermemizi sağlar.
-D, --new-datadir=Yeni
datadir dizinini göstermemizi sağlar. 
-j, --jobs=pg_upgrade sırasında aynı anda çalışacak process yada thread sayısını belirlememizi sağlar.
-k, --link=yeni cluster'a verilerin fiziksel olarak kopyalanması yerine verilerin linklenerek yeni cluster'a bağlanmasını sağlar. Bu yöntem ile pg_upgrade işlemini çok daha hızlı bitirecektir.

-v, --verbose=pg_upgrade çalışırken tüm sürece ait bilgileri aynı anda görebilmeyi sağlar.
-V, --version=pg_upgrade bittiğinde versiyonu görüntüler.

Bunun dışında diğer tüm seçenekler için pg_upgrade --help komutu ile görüntüleyebilirsiniz.

Pg_upgrade komutunu kullanmadan önce upgrade yapmayı istediğiniz yeni cluster'inizi oluşturmalısınız. Yani aynı sunucuya yeni bir PostgreSQL server kurmalısınız. 

PostgreSQL'in default portu 5432'dir. pg_upgrade öncesi kuracağınız yeni PostgreSQL servisini kontrol amaçlı restart etmek istediğinizde her iki PostgreSQL'in aynı portu kullanmasından dolayı hata almamak için yeni cluster'ınıza ait port numarasını geçici olarak 5432 dışında başka bir değer verebilirsiniz. 

pg_upgrade komutunu hazırladıktan sonra direk çalıştırılmasını önermiyoruz. Çalıştırmadan önce -c komutuyla iki cluster arasında yapılması planlanan upgrade işleminin başarılı olup olmayacağını görüntülemek yaşanacak sorunlar varsa eğer önlemi almamızı sağlayacaktır. Böylece komutu çalıştırmadan gerekli düzenlemeleri yapabileceğiz. Örneğin eski cluster üzerindeki eklentilerinizin hepsi postgresql<versiyon>-contrib paketinde bulunmayabilir(pgespresso gibi) bu paketlerin uygun sürümlerini hem master hem slave makinalarında upgrade öncesi kurmalısınız. Aksi takdirde pg_upgrade komutunu çalıştırdığınız anda upgrade yapmayı planladığınız sürüm için bu eklentileri kuramayacak hata ile karşılaşacaksınız. 

Gözden kaçabilecek eksiklikleri işe başlamadan temizlemek için -c komutunu kullanabilirsiniz.

-k komutunu verilerin hardcopy yapılmadan eski cluster'a symbolic link verilerek cluster'in upgrade olması için kullanabilirsiniz. Hardcopy'nin yapılması demek tüm verilerin yeni klasöre kopyalanması demek. Symbolic link verildiğinde veriler kopyalanmaz sadece yeni dosya dizininde eski dizin referans gösterilir. Verilerin kopyalanması durumu söz konusu olmadığı için k komutuyla upgrade işlemi daha hızlı biter.

-j komutunu kullanarak sürecin birden fazla process yada thread ile ilerletilmesini sağlayabilirsiniz. p parametresine ek kullnacağınız sayının ne olması gerektiği ile ilgili dikkat etmeniz konu şu: j parametresi CPU ve Disk sayısına bakar. CPU değeri 2 ve Disk sayısı 8 ise burada düşük olan sayı CPU'ya ait olduğu için -j 2 yazmamız gerekir. CPU 16 Disk 4 ise buradaki düşük olan sayı Disk'e ait olduğu için -j 4 yazabiliriz. Aksi taktirde upgrade işlemi sırasında IO yapması kaçınılmaz olur.

pg_upgrade sonrası yeni cluster'a ait konfigürasyon dosyaları yeniden tune edilmeli. Yedeklediğiniz konfigürasyon dosyalarından yada eski cluster içindeki konfigürasyon dosyalarından faydalanabilirsiniz.

Yeni cluster'a ait servisi başlatın. Sorun olup olmadığını görüntülemek için yeni cluster'inıza ait pg_log altındaki log dosyalarına bakmayı unutmayın.

pg_upgrade komutu başarılı çalıştıktan sonra çalıştırmamız için iki dosya oluşturacaktır.
  • analyze_new_cluster.sh
  • delete_old_cluster.sh
Analyze_new_cluster.sh dosyasının içinde oluşturulan script, default port olan 5432 için hazırlanır. Eğer farklı port üzerinde çalışıyorsanız bu scripte -p<port_numarası> şeklinde script sonuna kendi port bilginizi ekleyip manuel çalıştırmalısınız.

Sisteminizin düzgün çalıştığından emin olmadan delete_old_cluster.sh dosyasını çalıştırmamalısınız. Olabilecek herhangi bir durumda bu cluster'a ihtiyacınız olabilir.

Kurulum sırası şöyle olacaktır:

  • Yeni PostgreSQL server'i kurulmalı.
  • Pg_upgrade komutunu kullanmadan önce eski ve kurmuş olduğunuz yeni cluster'a ait servisleri kapatmalısınız.
  • -b, -B, -d, -D komutlarıyla yeni-eski bin ve datadir dizinlerini vererek pg_upgrade komutunu oluşturun.
  • Pg_upgrade sonrası yeni cluster'a ait konfigürasyon dosyalarını düzenlenmeli.
  • Yeni cluster'ın servisi başlatılmalı.
  • Loglar kontrol edilmeli. 

pg_upgrade örneği

PostgreSQL 9.6'dan 10'a upgrade işlemini yapalım.

Postgresql 9.6 kurulumu

yum install postgresql-96 postgresql-server
/usr/pgsql-9.6/bin/initdb -D /var/lib/pgsql/9.6/data
/usr/pgsql-9.6/bin/pg_ctl -D /var/lib/pgsql/9.6/data -l logfile start


Postgresql 10 kurulumu


yum install postgresql10*
/usr/pgsql-10/bin/initdb -D /var/lib/pgsql/10/data


PostgreSQL 9.6'ya ait servisi kapalıyken, PostgreSQL 10 servisini ayağa kaldıralım. Bir sorun olup olmamasına karşılık kontrol etmeyi tercih ediyorum her zaman.

/usr/pgsql-10/bin/pg_ctl -D /var/lib/pgsql/10/data -l logfile start

Sunucu yeniden başlatıldığında da PostgreSQL 10 servisinin de başlaması için;

systemctl enable postgresql-10


Her iki PostgreSQL versiyonuna ait servisleri pg_upgrade işlemini yapabilmek için kapatıyoruz.

/usr/pgsql-10/bin/pg_ctl stop -D /var/lib/pgsql/10/data/
/usr/pgsql-9.6/bin/pg_ctl stop -D /var/lib/pgsql/9.6/data/


Her iki cluster arasında pg_upgrade için bir farklılık olup olmadığı pg_upgrade komutunu c parametresini de ekleyerek kontrol edilir.

/usr/pgsql-10/bin/pg_upgrade -d /var/lib/pgsql/9.6/data/ -D /var/lib/pgsql/10/data/ -b /usr/pgsql-9.6/bin/ -B /usr/pgsql-10/bin/ -c



Performing Consistency Checks on Old Live Server
------------------------------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for invalid "unknown" user columns                 ok
Checking for hash indexes                                   ok
Checking for presence of required libraries                 ok
Checking database user is the install user                  ok
Checking for prepared transactions                          ok


*Clusters are compatible*

pg_upgrade komutunu c parametresi olmadan çalıştırabilirsiniz. Çalıştırmadan önce eski PostgreSQL servisi 9.6 olan durdurulmalı bu aşamada. Bir önce ki komutta bunu zaten yapmıştık. Yine de servisin durdurulmuş olup olmadığını kontrol etmek için aşağıdaki komutu kullanabilirsiniz.


/usr/pgsql-9.6/bin/pg_ctl status  -D /var/lib/pgsql/9.6/data/
 

pg_upgrade komutunu çalıştıralım. Hardcopy yerine yeni dizin üzerinde symbolic link yapmasını istiyorum. k parametresini ekliyorum. 

/usr/pgsql-10/bin/pg_upgrade -d /var/lib/pgsql/9.6/data/ -D /var/lib/pgsql/10/data/ -b /usr/pgsql-9.6/bin/ -B /usr/pgsql-10/bin/ -j 4 -k

Performing Consistency Checks
-----------------------------
Checking cluster versions ok
Checking database user is the install user ok
Checking database connection settings ok
Checking for prepared transactions ok
Checking for reg* data types in user tables ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for invalid "unknown" user columns ok
Creating dump of global objects ok
Creating dump of database schemas
ok
Checking for presence of required libraries ok
Checking database user is the install user ok
Checking for prepared transactions ok

If pg_upgrade fails after this point, you must re-initdb the

new cluster before continuing.

Performing Upgrade
------------------
Analyzing all rows in the new cluster ok
Freezing all rows in the new cluster ok
Deleting files from new pg_xact ok
Copying old pg_clog to new server ok
Setting next transaction ID and epoch for new cluster ok
Deleting files from new pg_multixact/offsets ok
Copying old pg_multixact/offsets to new server ok
Deleting files from new pg_multixact/members ok
Copying old pg_multixact/members to new server ok

Setting next multixact ID and offset for new cluster ok
Resetting WAL archives ok
Setting frozenxid and minmxid counters in new cluster ok
Restoring global objects in the new cluster ok
Restoring database schemas in the new cluster
ok
Adding ".old" suffix to old global/pg_control ok

If you want to start the old cluster, you will need to remove
the ".old" suffix from /var/lib/pgsql/9.6/data/global/pg_control.old.

Because "link" mode was used, the old cluster cannot be safely
started once the new cluster has been started.
 

Linking user relation files
ok
Setting next OID for new cluster ok
Sync data directory to disk ok
Creating script to analyze new cluster ok
Creating script to delete old cluster ok
Checking for hash indexes ok

Upgrade Complete
----------------
Optimizer statistics are not transferred by pg_upgrade so,
once you start the new server, consider running:
./analyze_new_cluster.sh

Running this script will delete the old cluster's data files:
./delete_old_cluster.sh


Yeni PostgreSQL servisi yani PG10 başlatılır.

/usr/pgsql-10/bin/pg_ctl start -D /var/lib/pgsql/10/data/

./analyze_new_cluster.sh komutu çalıştırılır. Bu dosyanın içinde çalıştırılacak bir satır kod vardır. o da aşağıdaki gibidir. 


"/usr/pgsql-10/bin/vacuumdb" --all --analyze-in-stages  

Eğer farklı port üzerinde çalıştırılıyorsa port verilerek manuel de çalıştırılabilir. PostgreSQL 10 servisini başlatmadan port numarasını 54323 olarak değiştirseydim vacuumdb komutum aşağıdaki gibi olacaktı. Örnek olarak şimdi port numarasını bu dosya içinde çalıştırılacak komutun sonuna ekliyorum.

"/usr/pgsql-10/bin/vacuumdb" --all --analyze-in-stages -p 54323


Tüm işlemler tamamlanınca PostgreSQL 10 servisi yeniden başlatabilirsiniz.

./delete_old_cluster.sh dosyasını yeni sisteminizin çalıştığından emin olduktan sonra çalıştırabilirsiniz.

Sevgiler,

Comments

Popular posts from this blog

pg_ctl: command not found

Hi, If you can not reach pg_ctl command in bash also you are sure this command exists in your server, check $PATH. -bash-4.2$ echo $PATH /usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin So, the directory of pg_ctl is not seem in PATH. Input directory of pg_ctl and check it then run it.

PostgreSQL Foreign Data Wrappers

Hi all, I would like to mention about generating Foreign Data Wrappers(FDW) on PostgreSQL 9.6. FDW is used for remote access to tables from external data storage. If needed to use remote table in a query, you can use FDW tables. For instance you can get a table from remote database, but there is a condition. The condition is that user should have proper privileges on FDW table. There is two extension for FDW on PostgreSQL. First one is used for accessing PostgreSQL database to PostgreSQL database, called postgres_fdw . Second one is used for accessing PostgreSQL database to different databases (SQL Server, Sysbase) called tds_fdw .  Foreign Data Wrappers feature lets you to cross-query between remote database tables. Postgres_fdw and tds_fdw has different structure. Tds_fdw usign Tabular Data Stream application layer protocol to transfer data between database server and client. Generating Tds_fdw and Postgres_fdw is similar. I share an example for generating FDW between two Po

PostgreSQL High Availability - Patroni 2

Patroni kurulumuyla ilgili oldukça fazla kaynak bulunmakta fakat kurulum ve yönetimini beraber barındıran kaynağa denk gelmedim. Bu yazıda hem Patroni kurulumu hem de kurulum sonrası yönetimiyle alakalı detaylara ulaşabilirsiniz. PostgreSQL cluster'larının yönetimi için kullanılan Patroni ile ilgili temel bilgilerin yer aldığı Autofailover üzerine hazırladığım yazı serisine aşağıdaki linklerden erişebilirsiniz. PostgreSQL ve Autofailover PostgreSQL'de Autofailover ve Patroni 1 (Giriş) PostgreSQL'de Autofailover ve Patroni 2 (Kurulum, Konfigürasyon ve Yönetim) PostgreSQL'de Autofailover ve Patroni 3 (Mevcut PostgreSQL Cluster'inin Patroni'ye Geçirilmesi) Patroni, PostgreSQL veritabanlarının kurulumundan ve konfigürasyonundan sorumludur. Yani Patroni'yi kurduğumuz sunucular aynı zamanda Patroni ile kurulmuş PostgreSQL'leri barındıracak. Üç node'lu PostgreSQL ve üç node'lu ETCD cluster'larını oluşturacağım. Kuruluma önce üç no