PostgreSQL
 sql >> Teknologi Basis Data >  >> RDS >> PostgreSQL

Migrasi PostgreSQL ke Cloud - Membandingkan Solusi dari Amazon, Google &Microsoft

Dari pandangan sekilas, tampaknya saat memigrasikan beban kerja PostgreSQL ke cloud, pilihan penyedia cloud seharusnya tidak ada bedanya. Di luar kotak, PostgreSQL memudahkan untuk mereplikasi data, tanpa downtime, melalui Replikasi Logis, meskipun dengan beberapa batasan. Untuk membuat penawaran layanan mereka lebih menarik, penyedia cloud dapat mengatasi beberapa batasan tersebut. Saat kami mulai memikirkan perbedaan dalam versi PostgreSQL yang tersedia, kompatibilitas, batasan, batasan, dan kinerja, menjadi jelas bahwa layanan migrasi merupakan faktor kunci dalam keseluruhan penawaran layanan. Ini bukan lagi kasus "kami menawarkannya, kami memigrasikannya". Ini menjadi lebih seperti "kami menawarkannya, kami memigrasikannya, dengan batasan paling sedikit".

Migrasi penting untuk organisasi kecil dan besar. Ini bukan tentang ukuran cluster PostgreSQL, tetapi tentang waktu henti yang dapat diterima dan upaya pascamigrasi.

Memilih Strategi

Strategi migrasi harus mempertimbangkan ukuran database, tautan jaringan antara sumber dan target, serta alat migrasi yang ditawarkan oleh penyedia cloud.

Perangkat Keras atau Perangkat Lunak?

Sama seperti mengirim kunci USB, dan DVD di masa awal Internet, dalam kasus di mana bandwidth jaringan tidak cukup untuk mentransfer data pada kecepatan yang diinginkan, penyedia cloud menawarkan solusi perangkat keras, dapat untuk membawa hingga ratusan petabyte data. Di bawah ini adalah solusi terkini dari masing-masing dari tiga besar:

Tabel praktis yang disediakan oleh Google menunjukkan opsi yang tersedia:

Peralatan GCP adalah Alat Transfer

Rekomendasi serupa dari Azure berdasarkan ukuran data vs bandwidth jaringan:

Alat Azure adalah kotak Data

Menjelang akhir halaman migrasi datanya, AWS memberikan gambaran sekilas tentang apa yang dapat kami harapkan, bersama dengan rekomendasi solusi mereka:

Jika ukuran basis data melebihi 100 GB dan bandwidth jaringan terbatas, AWS menyarankan solusi perangkat keras.

Alat AWS adalah Snowball Edge

Ekspor/Impor Data

Organisasi yang mentolerir waktu henti, dapat mengambil manfaat dari kesederhanaan alat umum yang disediakan oleh PostgreSQL secara langsung. Namun, saat memigrasikan data dari satu penyedia cloud (atau hosting) ke penyedia cloud lain, waspadalah terhadap biaya keluar.

AWS

Untuk menguji migrasi, saya menggunakan instalasi lokal database Nextcloud saya yang berjalan di salah satu server jaringan rumah saya:

postgres=# select pg_size_pretty(pg_database_size('nextcloud_prod'));

pg_size_pretty

----------------

58 MB

(1 row)



nextcloud_prod=# \dt

                     List of relations

Schema |             Name | Type  | Owner

--------+-------------------------------+-------+-----------

public | awsdms_ddl_audit              | table | s9sdemo

public | oc_accounts                   | table | nextcloud

public | oc_activity                   | table | nextcloud

public | oc_activity_mq                | table | nextcloud

public | oc_addressbookchanges         | table | nextcloud

public | oc_addressbooks               | table | nextcloud

public | oc_appconfig                  | table | nextcloud

public | oc_authtoken                  | table | nextcloud

public | oc_bruteforce_attempts        | table | nextcloud

public | oc_calendar_invitations       | table | nextcloud

public | oc_calendar_reminders         | table | nextcloud

public | oc_calendar_resources         | table | nextcloud

public | oc_calendar_resources_md      | table | nextcloud

public | oc_calendar_rooms             | table | nextcloud

public | oc_calendar_rooms_md          | table | nextcloud

...

public | oc_termsofservice_terms       | table | nextcloud

public | oc_text_documents             | table | nextcloud

public | oc_text_sessions              | table | nextcloud

public | oc_text_steps                 | table | nextcloud

public | oc_trusted_servers            | table | nextcloud

public | oc_twofactor_backupcodes      | table | nextcloud

public | oc_twofactor_providers        | table | nextcloud

public | oc_users                      | table | nextcloud

public | oc_vcategory                  | table | nextcloud

public | oc_vcategory_to_object        | table | nextcloud

public | oc_whats_new                  | table | nextcloud

(84 rows)

The database is running PostgreSQL version 11.5:

postgres=# select version();

                                                version

------------------------------------------------------------------------------------------------------------

PostgreSQL 11.5 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1), 64-bit

(1 row)

Saya juga telah membuat pengguna PostgreSQL untuk digunakan oleh AWS DMS yang merupakan layanan Amazon untuk mengimpor PostgreSQL ke Amazon RDS:

postgres=# \du s9sdemo

            List of roles

Role name | Attributes |  Member of

-----------+------------+-------------

s9sdemo   |   | {nextcloud}

AWS DMS memberikan banyak keuntungan, seperti yang kami harapkan dari solusi terkelola di cloud: 

  • penskalaan otomatis (hanya penyimpanan, karena instance komputasi harus berukuran tepat)
  •  penyediaan otomatis
  •  model bayar sesuai pemakaian
  •  pengalihan otomatis

Namun, menjaga konsistensi data untuk database langsung adalah upaya terbaik. Konsistensi 100% tercapai hanya jika database dalam mode hanya-baca — itu adalah konsekuensi dari cara perubahan tabel ditangkap.

Dengan kata lain, tabel memiliki cutover point-in-time yang berbeda:

Sama seperti semua yang ada di awan, ada biaya yang terkait dengan layanan migrasi.

Untuk membuat lingkungan migrasi, ikuti panduan Memulai untuk menyiapkan instance replikasi, sumber, titik akhir target, dan satu atau beberapa tugas.

Instance Replikasi

Membuat instans replikasi sangat mudah bagi siapa saja yang terbiasa dengan instans EC2 di AWS:

Satu-satunya perubahan dari default adalah memilih AWS DMS 3.3.0 atau nanti karena mesin PostgreSQL lokal saya menjadi 11.5:

Dan inilah daftar versi AWS DMS yang tersedia saat ini:

Penginstalan besar juga harus memperhatikan Batas DMS AWS:

Ada juga serangkaian batasan yang merupakan konsekuensi dari replikasi logis PostgreSQL pembatasan. Misalnya, AWS DMS tidak akan memigrasikan objek sekunder:

Perlu disebutkan bahwa di PostgreSQL semua indeks adalah indeks sekunder, dan itu bukanlah hal yang buruk, seperti yang disebutkan dalam diskusi yang lebih rinci ini.

Titik Akhir Sumber

Ikuti wizard untuk membuat Titik Akhir Sumber:

Dalam skenario penyiapan Konfigurasi untuk Jaringan ke VPC Menggunakan Internet my jaringan rumah memerlukan beberapa penyesuaian agar alamat IP titik akhir sumber dapat mengakses server internal saya. Pertama, saya membuat penerusan port pada router tepi (173.180.222.170) untuk mengirim lalu lintas pada port 30485 ke gateway internal saya (10.11.11.241) pada port 5432 di mana saya dapat menyesuaikan akses berdasarkan alamat IP sumber melalui aturan iptables. Dari sana, lalu lintas jaringan mengalir melalui terowongan SSH ke server web yang menjalankan database PostgreSQL. Dengan konfigurasi yang dijelaskan, client_addr dalam output pg_stat_activity akan muncul sebagai 127.0.0.1.

Sebelum mengizinkan lalu lintas masuk, log iptables menunjukkan 12 upaya dari instance replikasi di ip=3.227.167.58):

Jan 19 17:35:28 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23973 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:29 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23974 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:31 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23975 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:35 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=23976 DF PROTO=TCP SPT=54662 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:48 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4328 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:49 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4329 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:51 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4330 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:35:55 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=4331 DF PROTO=TCP SPT=54667 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:08 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8298 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:09 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8299 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:11 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8300 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Jan 19 17:36:16 mha.can.local kernel: filter/INPUT: IN=enp0s29f7u2 OUT= MAC=00:24:9b:17:3a:fa:9c:1e:95:e5:ad:b0:08:00 SRC=3.227.167.58 DST=10.11.11.241 LEN=60 TOS=0x00 PREC=0x00 TTL=39 ID=8301 DF PROTO=TCP SPT=54670 DPT=5432 WINDOW=26880 RES=0x00 SYN URGP=0

Setelah mengizinkan alamat IP titik akhir sumber (3.227.167.58), uji koneksi berhasil dan konfigurasi titik akhir sumber selesai. Kami juga memiliki koneksi SSL untuk mengenkripsi lalu lintas melalui jaringan publik. Ini dapat dikonfirmasi di server PostgreSQL menggunakan kueri di bawah ini serta di konsol AWS:

postgres=# SELECT datname, usename, client_addr, ssl, cipher, query, query_start FROM pg_stat_activity a, pg_stat_ssl s where a.pid=s.pid and usename = 's9sdemo';

datname | usename | client_addr | ssl | cipher | query | query_start

---------+---------+-------------+-----+--------+-------+-------------

(0 rows)

…lalu tonton saat menjalankan koneksi dari konsol AWS. Hasilnya akan terlihat seperti berikut:

postgres=# \watch



                                                                           Sun 19 Jan 2020 06:50:51 PM PST (every 2s)



    datname     | usename | client_addr | ssl |           cipher |                 query | query_start

----------------+---------+-------------+-----+-----------------------------+------------------------------------------------------------------------------------+-------------------------------

 nextcloud_prod | s9sdemo | 127.0.0.1   | t | ECDHE-RSA-AES256-GCM-SHA384 | select cast(setting as integer) from pg_settings where name = 'server_version_num' | 2020-01-19 18:50:51.463496-08

(1 row)

…sementara konsol AWS harus melaporkan keberhasilan:

Seperti yang ditunjukkan di bagian prasyarat, jika kita memilih opsi migrasi Beban penuh , replikasi yang sedang berlangsung, kita perlu mengubah izin untuk pengguna PostgreSQL. Opsi migrasi ini memerlukan hak pengguna super, oleh karena itu saya menyesuaikan pengaturan untuk pengguna PostgreSQL yang dibuat sebelumnya:

nextcloud_prod=# \du s9sdemo

         List of roles

Role name | Attributes | Member of

-----------+------------+-----------

s9sdemo   | Superuser  | {}

Dokumen yang sama berisi instruksi untuk memodifikasi postgresql.conf. Ini perbedaan dari yang asli:

--- a/var/lib/pgsql/data/postgresql.conf

+++ b/var/lib/pgsql/data/postgresql.conf

@@ -95,7 +95,7 @@ max_connections = 100                 # (change requires restart)



# - SSL -



-#ssl = off

+ssl = on

#ssl_ca_file = ''

#ssl_cert_file = 'server.crt'

#ssl_crl_file = ''

@@ -181,6 +181,7 @@ dynamic_shared_memory_type = posix  # the default is the first option



# - Settings -



+wal_level = logical

#wal_level = replica                   # minimal, replica, or logical

                                       # (change requires restart)

#fsync = on                            # flush data to disk for crash safety

@@ -239,6 +240,7 @@ min_wal_size = 80MB

#max_wal_senders = 10          # max number of walsender processes

                              # (change requires restart)

#wal_keep_segments = 0         # in logfile segments; 0 disables

+wal_sender_timeout = 0

#wal_sender_timeout = 60s      # in milliseconds; 0 disables



#max_replication_slots = 10    # max number of replication slots

@@ -451,6 +453,7 @@ log_rotation_size = 0                       # Automatic rotation of logfiles will

#log_duration = off

#log_error_verbosity = default         # terse, default, or verbose messages

Terakhir, jangan lupa untuk menyesuaikan pengaturan pg_hba.conf untuk mengizinkan koneksi SSL dari alamat IP instance replikasi.

Kami sekarang siap untuk langkah selanjutnya.

Titik Akhir Target

Ikuti wizard untuk membuat Target Endpoint:

Langkah ini mengasumsikan bahwa instance RDS dengan titik akhir yang ditentukan sudah ada bersama dengan database kosong nextcloud_awsdms. Basis data dapat dibuat selama penyiapan instans RDS.

Pada titik ini, jika jaringan AWS diatur dengan benar, kita harus siap menjalankan uji koneksi:

Dengan lingkungan yang ada, sekarang saatnya membuat tugas migrasi :

Tugas Migrasi

Setelah wizard selesai, konfigurasi akan terlihat seperti ini:

...dan bagian kedua dari tampilan yang sama:

Setelah tugas dimulai, kita dapat memantau kemajuan —buka tugas detail dan gulir ke bawah ke Tabel Statistik:

 AWS DMS menggunakan skema cache untuk memigrasi tabel database. Saat migrasi berlangsung, kami dapat terus "menonton" kueri di database sumber, dan log kesalahan PostgreSQL, selain di konsol AWS:

Jika terjadi kesalahan, status kegagalan ditampilkan di konsol:

Satu tempat untuk mencari petunjuk adalah CloudWatch, meskipun selama pengujian saya log tidak dipublikasikan, yang mungkin hanya merupakan kesalahan lain dalam versi beta AWS DMS 3.3.0 yang ternyata menjelang akhir latihan ini:

Progres migrasi ditampilkan dengan baik di konsol AWS DMS:

Setelah migrasi selesai, meninjau sekali lagi, log kesalahan PostgreSQL , mengungkapkan pesan mengejutkan:

Apa yang tampaknya terjadi, adalah bahwa di PostgreSQL 9.6, 10 tabel pg_class berisi kolom bernama relhaspkey, tapi itu tidak terjadi di 11. Dan itulah kesalahan dalam versi beta AWS DMS 3.3.0 yang saya maksud sebelumnya.

GCP

Pendekatan Google didasarkan pada alat sumber terbuka PgBouncer. Kegembiraan itu tidak berlangsung lama, karena dokumentasi resmi berbicara tentang migrasi PostgreSQL ke lingkungan mesin komputasi.

Upaya lebih lanjut untuk menemukan solusi migrasi ke Cloud SQL yang menyerupai AWS DMS gagal. Strategi migrasi Database tidak mengandung referensi ke PostgreSQL:

Penginstalan PostgreSQL lokal dapat dimigrasikan ke Cloud SQL dengan menggunakan layanan salah satu partner Google Cloud.

Solusi potensial mungkin adalah PgBouncer untuk Cloud SQL, tetapi itu tidak termasuk dalam cakupan blog ini.

Layanan Cloud Microsoft (Azure)

Untuk memfasilitasi migrasi beban kerja PostgreSQL dari lokal ke Database Azure terkelola untuk PostgreSQL, Microsoft menyediakan Azure DMS yang menurut dokumentasi dapat digunakan untuk bermigrasi dengan waktu henti minimal. Tutorial Migrasi PostgreSQL ke Azure Database untuk PostgreSQL online menggunakan DMS menjelaskan langkah-langkah ini secara mendetail.

Dokumentasi Azure DMS membahas dengan sangat rinci masalah dan batasan yang terkait dengan migrasi beban kerja PostgreSQL ke Azure.

Satu perbedaan penting dari AWS DMS adalah persyaratan untuk membuat skema secara manual:

Demo ini akan menjadi topik blog masa depan. Pantau terus.


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. Evolusi Toleransi Kesalahan di PostgreSQL:Perjalanan Waktu

  2. Tidak dapat membuat layanan yang diminta [org.hibernate.engine.jdbc.env.spi.JdbcEnvironment]

  3. Bagaimana cara menonaktifkan sementara pemicu di PostgreSQL?

  4. Basis data default bernama postgres di server Postgresql

  5. Django cache.set() menyebabkan kesalahan kunci duplikat