Mengubah ukuran cluster - Amazon Redshift

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Mengubah ukuran cluster

Karena kapasitas dan kinerja pergudangan data Anda perlu berubah, Anda dapat mengubah ukuran klaster Anda untuk memanfaatkan opsi komputasi dan penyimpanan Amazon Redshift sebaik mungkin.

Operasi pengubahan ukuran datang dalam dua jenis:

  • Ubah ukuran elastis — Anda dapat menambahkan node ke atau menghapus node dari cluster Anda. Anda juga dapat mengubah jenis node, seperti dari node DS2 ke node RA3. Pengubahan ukuran elastis biasanya selesai dengan cepat, rata-rata memakan waktu sepuluh menit. Untuk alasan ini, kami merekomendasikannya sebagai opsi pertama. Ketika Anda melakukan pengubahan ukuran elastis, itu mendistribusikan ulang irisan data, yang merupakan partisi yang dialokasikan memori dan ruang disk di setiap node. Pengubahan ukuran elastis sesuai saat Anda:

    • Tambahkan atau kurangi node di cluster yang ada, tetapi Anda tidak mengubah jenis node — Ini biasa disebut pengubahan ukuran di tempat. Saat Anda melakukan jenis pengubahan ukuran ini, beberapa kueri yang berjalan berhasil diselesaikan, tetapi yang lain dapat dihapus sebagai bagian dari operasi.

    • Ubah tipe node untuk cluster — Saat Anda mengubah tipe node, snapshot dibuat dan data didistribusikan kembali dari cluster sumber ke cluster yang terdiri dari tipe node baru. Setelah selesai, kueri yang berjalan dijatuhkan. Seperti pengubahan ukuran di tempat, itu selesai dengan cepat.

  • Pengubahan ukuran klasik - Anda dapat mengubah jenis node, jumlah node, atau keduanya, dengan cara yang mirip dengan pengubahan ukuran elastis. Pengubahan ukuran klasik membutuhkan lebih banyak waktu untuk diselesaikan, tetapi ini dapat berguna dalam kasus di mana perubahan jumlah node atau tipe node yang akan dimigrasi tidak termasuk dalam batas untuk mengubah ukuran elastis. Ini dapat diterapkan, misalnya, ketika perubahan jumlah node sangat besar.

Ubah ukuran elastis

Operasi pengubahan ukuran elastis, ketika Anda menambah atau menghapus node dari jenis yang sama, memiliki tahapan berikut:

  1. Pengubahan ukuran elastis membutuhkan snapshot cluster. Snapshot ini selalu menyertakan tabel tanpa cadangan untuk node yang berlaku. (Beberapa tipe node, seperti RA3, tidak memiliki tabel tanpa cadangan.) Jika klaster Anda tidak memiliki snapshot terbaru, karena Anda menonaktifkan snapshot otomatis, operasi pencadangan dapat memakan waktu lebih lama. (Untuk meminimalkan waktu sebelum operasi pengubahan ukuran dimulai, kami sarankan Anda mengaktifkan snapshot otomatis atau membuat snapshot manual sebelum memulai pengubahan ukuran.) Saat Anda memulai pengubahan ukuran elastis dan operasi snapshot sedang berlangsung, pengubahan ukuran dapat gagal jika operasi snapshot tidak selesai dalam beberapa menit. Untuk informasi selengkapnya, lihat Cuplikan dan cadangan Amazon Redshift.

  2. Operasi memigrasikan metadata cluster. Cluster tidak tersedia selama beberapa menit. Mayoritas kueri dijeda sementara dan koneksi tetap terbuka. Namun, ada kemungkinan untuk beberapa kueri dihapus. Tahap ini singkat.

  3. Koneksi sesi dipulihkan dan kueri dilanjutkan.

  4. Pengubahan ukuran elastis mendistribusikan kembali data ke irisan simpul, di latar belakang. Cluster tersedia untuk operasi baca dan tulis, tetapi beberapa kueri dapat memakan waktu lebih lama untuk dijalankan.

  5. Setelah operasi selesai, Amazon Redshift mengirimkan pemberitahuan acara.

Saat Anda menggunakan pengubahan ukuran elastis untuk mengubah tipe node, ia bekerja sama dengan saat Anda menambahkan atau mengurangi node dari tipe yang sama. Pertama, snapshot dibuat. Kluster target baru disediakan dengan data terbaru dari snapshot, dan data ditransfer ke cluster baru di latar belakang. Selama periode ini, data hanya dibaca. Saat pengubahan ukuran hampir selesai, Amazon Redshift memperbarui titik akhir untuk menunjuk ke cluster baru dan semua koneksi ke cluster sumber dihapus.

Tidak mungkin pengubahan ukuran elastis akan gagal. Namun, dalam kasus kegagalan, rollback terjadi secara otomatis di sebagian besar kasus tanpa memerlukan intervensi manual.

Jika Anda memiliki node cadangan, misalnya node cadangan DS2, Anda dapat meningkatkan ke node cadangan RA3 saat Anda melakukan pengubahan ukuran. Anda dapat melakukan ini ketika Anda melakukan pengubahan ukuran elastis atau menggunakan konsol untuk memulihkan dari snapshot. Konsol memandu Anda melalui proses ini. Untuk informasi selengkapnya tentang memutakhirkan ke node RA3, lihat Memutakhirkan ke tipe node RA3.

Pengubahan ukuran elastis tidak mengurutkan tabel atau merebut kembali ruang disk, jadi ini bukan pengganti operasi vakum. Untuk informasi lebih lanjut, lihat tabel Menyedot debu.

Ubah ukuran elastis memiliki kendala berikut:

  • Kluster pengubahan ukuran dan berbagi data yang elastis - Saat menambahkan atau mengurangi node pada klaster yang merupakan produsen untuk berbagi data, Anda tidak dapat menghubungkannya dari konsumen saat Amazon Redshift memigrasikan metadata klaster. Demikian pula, jika Anda melakukan pengubahan ukuran elastis dan memilih tipe node baru, berbagi data tidak tersedia saat koneksi dijatuhkan dan ditransfer ke cluster target baru. Dalam kedua jenis pengubahan ukuran elastis, produsen tidak tersedia selama beberapa menit.

  • Transfer data dari snapshot bersama - Untuk menjalankan pengubahan ukuran elastis pada klaster yang mentransfer data dari snapshot bersama, setidaknya satu cadangan harus tersedia untuk klaster. Anda dapat melihat cadangan di daftar snapshot konsol Amazon Redshift, perintah describe-cluster-snapshots CLI, atau operasi API. DescribeClusterSnapshots

  • Pembatasan platform - Pengubahan ukuran elastis hanya tersedia untuk cluster yang menggunakan platform EC2-VPC. Untuk informasi selengkapnya, lihat Gunakan EC2-VPC saat Anda membuat cluster.

  • Pertimbangan penyimpanan - Pastikan konfigurasi node baru Anda memiliki penyimpanan yang cukup untuk data yang ada. Anda mungkin harus menambahkan node tambahan atau mengubah konfigurasi.

  • Ukuran cluster sumber vs target - Jumlah node dan tipe node yang dapat diubah ukurannya dengan pengubahan ukuran elastis ditentukan oleh jumlah node di cluster sumber dan tipe node yang dipilih untuk cluster yang diubah ukurannya. Untuk menentukan kemungkinan konfigurasi yang tersedia, Anda dapat menggunakan konsol. Atau Anda dapat menggunakan describe-node-configuration-options AWS CLI perintah dengan action-type resize-cluster opsi. Untuk informasi selengkapnya tentang mengubah ukuran menggunakan konsol Amazon Redshift, lihat. Mengubah ukuran cluster

    Contoh perintah CLI berikut menjelaskan opsi konfigurasi yang tersedia. Dalam contoh ini, cluster bernama mycluster adalah cluster dc2.large 8-node.

    aws redshift describe-node-configuration-options --cluster-identifier mycluster --region eu-west-1 --action-type resize-cluster

    Perintah ini mengembalikan daftar opsi dengan jenis node yang direkomendasikan, jumlah node, dan pemanfaatan disk untuk setiap opsi. Konfigurasi yang dikembalikan dapat bervariasi berdasarkan cluster input tertentu. Anda dapat memilih salah satu konfigurasi yang dikembalikan saat Anda menentukan opsi perintah resize-cluster CLI.

  • Langit-langit pada node tambahan - Ubah ukuran elastis memiliki batas pada node yang dapat Anda tambahkan ke cluster. Misalnya, cluster dc2 mendukung pengubahan ukuran elastis hingga menggandakan jumlah node. Untuk mengilustrasikan, Anda dapat menambahkan node ke cluster dc2.8xlarge 4-node untuk menjadikannya cluster lima simpul, atau menambahkan lebih banyak node hingga Anda mencapai delapan.

    catatan

    Batas pertumbuhan dan pengurangan didasarkan pada jenis node asli dan jumlah node di cluster asli atau pengubahan ukuran klasik terakhirnya. Jika pengubahan ukuran elastis akan melebihi batas pertumbuhan atau pengurangan, gunakan pengubahan ukuran klasik.

    Dengan beberapa tipe node ra3, Anda dapat meningkatkan jumlah node hingga empat kali jumlah yang ada. Secara khusus, anggaplah cluster Anda terdiri dari node ra3.4xlarge atau ra3.16xlarge. Anda kemudian dapat menggunakan pengubahan ukuran elastis untuk meningkatkan jumlah node dalam cluster 8-node menjadi 32. Atau Anda dapat memilih nilai di bawah batas. (Perlu diingat bahwa kemampuan untuk menumbuhkan cluster sebesar 4x tergantung pada ukuran cluster sumber.) Jika cluster Anda memiliki node ra3.xlplus, batasnya dua kali lipat.

    Semua tipe node ra3 mendukung penurunan jumlah node menjadi seperempat dari jumlah yang ada. Misalnya, Anda dapat mengurangi ukuran cluster dengan node ra3.4xlarge dari 12 node menjadi 3, atau ke angka di atas minimum.

    Tabel berikut mencantumkan batas pertumbuhan dan pengurangan untuk setiap jenis node yang mendukung pengubahan ukuran elastis.

    Jenis simpul asli Batas pertumbuhan Batas pengurangan

    ra3.16xlarge

    4x (dari 4 hingga 16 node, misalnya)

    Untuk seperempat dari jumlah (dari 16 hingga 4 node, misalnya)

    ra3.4xlarge

    4x

    Untuk seperempat dari jumlah

    ra3.xlplus

    2x (dari 4 hingga 8 node, misalnya)

    Untuk seperempat dari jumlah

    dc2.8xlarge

    2x

    Untuk setengah dari jumlah (dari 16 hingga 8 node, misalnya)

    dc2.large

    2x

    Setengah dari jumlah

    ds2.8xlarge

    2x

    Setengah dari jumlah

    ds2.xlarge

    2x

    Setengah dari jumlah

    catatan

    Memilih tipe node lama saat Anda mengubah ukuran cluster RA3 — Jika Anda mencoba mengubah ukuran dari cluster dengan node RA3 ke tipe node lain, seperti DC2 atau DS2, pesan peringatan validasi akan muncul di konsol, dan operasi pengubahan ukuran tidak akan selesai. Ini terjadi karena mengubah ukuran ke tipe simpul lama tidak didukung. Ini untuk mencegah pelanggan mengubah ukuran ke jenis node yang tidak digunakan lagi atau segera tidak digunakan lagi. Ini berlaku untuk pengubahan ukuran elastis dan pengubahan ukuran klasik.

Ubah ukuran klasik

Pengubahan ukuran klasik menangani kasus penggunaan di mana perubahan ukuran cluster atau tipe node tidak didukung oleh pengubahan ukuran elastis. Saat Anda melakukan pengubahan ukuran klasik, Amazon Redshift membuat kluster target dan memigrasikan data dan metadata Anda ke klaster sumber.

Pengubahan ukuran klasik ke RA3 dapat memberikan ketersediaan yang lebih baik

Pengubahan ukuran klasik telah ditingkatkan ketika tipe node target adalah RA3. Hal ini dilakukan dengan menggunakan backup dan restore operasi antara sumber dan target cluster. Ketika pengubahan ukuran dimulai, cluster sumber dimulai ulang dan tidak tersedia selama beberapa menit. Setelah itu, cluster tersedia untuk operasi baca dan tulis sementara pengubahan ukuran berlanjut di latar belakang.

Memeriksa cluster Anda

Untuk memastikan Anda memiliki kinerja dan hasil terbaik saat Anda melakukan pengubahan ukuran klasik ke cluster RA3, lengkapi daftar periksa ini. Ketika Anda tidak mengikuti daftar periksa, Anda mungkin tidak mendapatkan beberapa manfaat dari mengubah ukuran klasik dengan node RA3, seperti kemampuan untuk melakukan operasi baca dan tulis.

  1. Ukuran data harus di bawah 2 petabyte. (Satu petabyte sama dengan 1.000 terabyte.) Untuk memvalidasi ukuran data Anda, buat snapshot dan periksa ukurannya. Anda juga dapat menjalankan kueri berikut untuk memeriksa ukurannya:

    SELECT sum(case when lower(diststyle) like ('%key%') then size else 0 end) distkey_blocks, sum(size) as total_blocks, ((distkey_blocks/(total_blocks*1.00)))*100 as Blocks_need_redist FROM svv_table_info;

    svv_table_infoTabel hanya terlihat oleh pengguna super.

  2. Sebelum Anda memulai pengubahan ukuran klasik, pastikan Anda memiliki snapshot manual yang tidak lebih dari 10 jam. Jika tidak, ambil snapshot.

  3. Snapshot yang digunakan untuk melakukan pengubahan ukuran klasik tidak dapat digunakan untuk pemulihan tabel atau tujuan lain.

  4. Cluster harus dalam VPC.

Operasi penyortiran dan distribusi yang dihasilkan dari pengubahan ukuran klasik ke RA3

Selama pengubahan ukuran klasik ke RA3, tabel dengan distribusi KEY yang dimigrasikan sebagai distribusi EVEN dikonversi kembali ke gaya distribusi aslinya. Durasi ini tergantung pada ukuran data dan seberapa sibuk cluster Anda. Beban kerja kueri diberikan prioritas yang lebih tinggi untuk menjalankan migrasi data. Untuk informasi selengkapnya, lihat Gaya distribusi. Baik membaca dan menulis ke database bekerja selama proses migrasi ini, tetapi dapat memakan waktu lebih lama untuk menyelesaikan kueri. Namun, penskalaan konkurensi dapat meningkatkan kinerja selama waktu ini dengan menambahkan sumber daya untuk beban kerja kueri. Anda dapat melihat kemajuan migrasi data dengan melihat hasil dari tampilan SYS_RESTORE_STATE dan SYS_RESTORE_LOG. Informasi lebih lanjut tentang pemantauan berikut.

Setelah cluster diubah ukurannya sepenuhnya, perilaku pengurutan berikut terjadi:

  • Jika pengubahan ukuran menghasilkan cluster yang memiliki lebih banyak irisan, tabel distribusi KEY menjadi sebagian tidak disortir, tetapi tabel EVEN tetap diurutkan. Selain itu, informasi tentang berapa banyak data yang diurutkan mungkin tidak mutakhir, langsung mengikuti pengubahan ukuran. Setelah pemulihan kunci, vakum otomatis menyortir tabel dari waktu ke waktu.

  • Jika pengubahan ukuran menghasilkan cluster yang memiliki irisan lebih sedikit, distribusi KEY dan tabel distribusi EVEN menjadi sebagian tidak disortir. Vakum otomatis menyortir meja dari waktu ke waktu.

Untuk informasi lebih lanjut tentang vakum meja otomatis, lihat Menyedot debu tabel. Untuk informasi selengkapnya tentang irisan di node komputasi, lihat Arsitektur sistem gudang data.

Langkah mengubah ukuran klasik saat cluster target adalah RA3

Pengubahan ukuran klasik terdiri dari langkah-langkah berikut, ketika tipe cluster target adalah RA3 dan Anda telah memenuhi prasyarat yang dirinci di bagian sebelumnya.

  1. Migrasi dimulai dari cluster sumber ke cluster target. Saat kluster target baru disediakan, Amazon Redshift mengirimkan pemberitahuan peristiwa bahwa pengubahan ukuran telah dimulai. Ini memulai ulang cluster Anda yang ada, yang menutup semua koneksi. Jika klaster Anda yang ada adalah cluster produsen berbagi data, koneksi dengan cluster konsumen juga ditutup. Restart membutuhkan waktu beberapa menit.

    Perhatikan bahwa setiap relasi database, seperti tabel atau tampilan terwujud, dibuat dengan tidak BACKUP NO dipertahankan selama pengubahan ukuran klasik. Untuk informasi selengkapnya, lihat MEMBUAT TAMPILAN TERWUJUD.

  2. Setelah restart, database tersedia untuk dibaca dan ditulis. Selain itu, berbagi data dilanjutkan, yang membutuhkan beberapa menit tambahan.

  3. Data dimigrasikan ke cluster target. Ketika tipe node target adalah RA3, membaca dan menulis tersedia selama migrasi data.

  4. Saat proses pengubahan ukuran hampir selesai, Amazon Redshift memperbarui titik akhir ke kluster target, dan semua koneksi ke cluster sumber akan dihapus. Cluster target menjadi produsen untuk berbagi data.

  5. Pengubahan ukuran selesai. Amazon Redshift mengirimkan pemberitahuan acara.

Anda dapat melihat kemajuan pengubahan ukuran di konsol Amazon Redshift. Waktu yang dibutuhkan untuk mengubah ukuran cluster tergantung pada jumlah data.

catatan

Memilih tipe node lama saat Anda mengubah ukuran cluster RA3 — Jika Anda mencoba mengubah ukuran dari cluster dengan node RA3 ke tipe node lain, seperti DC2 atau DS2, pesan peringatan validasi akan muncul di konsol, dan operasi pengubahan ukuran tidak akan selesai. Ini terjadi karena mengubah ukuran ke tipe simpul lama tidak didukung. Ini untuk mencegah pelanggan mengubah ukuran ke jenis node yang tidak digunakan lagi atau segera tidak digunakan lagi. Ini berlaku untuk pengubahan ukuran elastis dan pengubahan ukuran klasik.

Memantau pengubahan ukuran klasik saat cluster target adalah RA3

Untuk memantau pengubahan ukuran klasik dari klaster yang disediakan yang sedang berlangsung, termasuk distribusi KEY, gunakan SYS_RESTORE_STATE. Ini menunjukkan persentase selesai untuk tabel yang dikonversi. Anda harus menjadi pengguna super untuk mengakses data.

Jatuhkan tabel yang tidak Anda butuhkan saat Anda melakukan pengubahan ukuran klasik. Ketika Anda melakukan ini, tabel yang ada dapat didistribusikan lebih cepat.

Langkah mengubah ukuran klasik saat cluster target bukan RA3

Pengubahan ukuran klasik terdiri dari yang berikut ini, ketika tipe node target adalah apa pun selain RA3, seperti DS2, misalnya.

  1. Migrasi dimulai dari cluster sumber ke cluster target. Saat kluster target baru disediakan, Amazon Redshift mengirimkan pemberitahuan peristiwa bahwa pengubahan ukuran telah dimulai. Ini memulai ulang cluster Anda yang ada, yang menutup semua koneksi. Jika klaster Anda yang ada adalah cluster produsen berbagi data, koneksi dengan cluster konsumen juga ditutup. Restart membutuhkan waktu beberapa menit.

    Perhatikan bahwa setiap relasi database, seperti tabel atau tampilan terwujud, dibuat dengan tidak BACKUP NO dipertahankan selama pengubahan ukuran klasik. Untuk informasi selengkapnya, lihat MEMBUAT TAMPILAN TERWUJUD.

  2. Setelah restart, database tersedia hanya sebagai baca. Berbagi data dilanjutkan, yang membutuhkan beberapa menit tambahan.

  3. Data dimigrasikan ke cluster target. Database tetap dibaca saja.

  4. Saat proses pengubahan ukuran hampir selesai, Amazon Redshift memperbarui titik akhir ke kluster target, dan semua koneksi ke cluster sumber akan dihapus. Cluster target menjadi produsen untuk berbagi data.

  5. Pengubahan ukuran selesai. Amazon Redshift mengirimkan pemberitahuan acara.

Anda dapat melihat kemajuan pengubahan ukuran di konsol Amazon Redshift. Waktu yang dibutuhkan untuk mengubah ukuran cluster tergantung pada jumlah data.

catatan

Diperlukan waktu berhari-hari atau mungkin berminggu-minggu untuk mengubah ukuran cluster dengan sejumlah besar data ketika cluster target bukan RA3, atau tidak memenuhi prasyarat untuk kluster target RA3 yang dirinci di bagian sebelumnya.

Perhatikan juga bahwa kapasitas penyimpanan yang digunakan untuk cluster dapat naik setelah mengubah ukuran klasik. Ini adalah perilaku sistem normal ketika cluster memiliki irisan data tambahan yang dihasilkan dari pengubahan ukuran klasik. Penggunaan kapasitas tambahan ini dapat terjadi bahkan ketika jumlah node di cluster tetap sama.

Ubah ukuran elastis vs ukuran klasik

Tabel berikut membandingkan perilaku antara dua jenis pengubahan ukuran.

Ubah ukuran elastis vs ukuran klasik
Perilaku Ubah ukuran elastis Ubah ukuran klasik Komentar
Retensi data sistem Pengubahan ukuran elastis mempertahankan data log sistem. Pengubahan ukuran klasik tidak menyimpan tabel dan data sistem. Jika Anda mengaktifkan pencatatan audit di kluster sumber, Anda dapat terus mengakses log di Amazon S3 atau di CloudWatch, setelah mengubah ukuran. Anda dapat menyimpan atau menghapus log ini seperti yang ditentukan oleh kebijakan data Anda.
Mengubah jenis node

Ubah ukuran elastis, ketika tipe node tidak berubah: Ubah ukuran di tempat, dan sebagian besar kueri ditahan.

Ubah ukuran elastis, dengan tipe node baru dipilih: Sebuah cluster baru dibuat. Kueri dijatuhkan saat proses pengubahan ukuran selesai.

Classic Resize: Sebuah cluster baru dibuat. Kueri dijatuhkan selama proses pengubahan ukuran.
Sesi dan retensi kueri Pengubahan ukuran elastis mempertahankan sesi dan kueri saat tipe node sama di cluster sumber dan target. Jika Anda memilih jenis node baru, kueri akan dihapus. Pengubahan ukuran klasik tidak mempertahankan sesi dan kueri. Pertanyaan dijatuhkan. Saat kueri dihapus, Anda dapat mengharapkan beberapa penurunan kinerja. Yang terbaik adalah melakukan operasi pengubahan ukuran selama periode penggunaan ringan.
Membatalkan operasi pengubahan ukuran

Anda tidak dapat membatalkan pengubahan ukuran elastis.

Anda dapat membatalkan operasi pengubahan ukuran klasik sebelum selesai dengan memilih Batalkan pengubahan ukuran dari detail cluster di konsol Amazon Redshift.

Jumlah waktu yang diperlukan untuk membatalkan pengubahan ukuran tergantung pada tahap operasi pengubahan ukuran saat Anda membatalkan. Saat Anda melakukan ini, klaster tidak tersedia sampai operasi pembatalan selesai. Jika operasi pengubahan ukuran berada di tahap akhir, Anda tidak dapat membatalkan.

Untuk mengubah ukuran klasik ke cluster RA3, Anda tidak dapat membatalkan.

Menjadwalkan pengubahan ukuran

Anda dapat menjadwalkan operasi pengubahan ukuran untuk klaster Anda untuk ditingkatkan guna mengantisipasi penggunaan yang tinggi atau untuk mengurangi penghematan biaya. Penjadwalan berfungsi untuk pengubahan ukuran elastis dan pengubahan ukuran klasik. Anda dapat mengatur jadwal di konsol Amazon Redshift. Untuk informasi selengkapnya, lihatMengubah ukuran cluster, di bagian Mengelola kluster menggunakan konsol. Anda juga dapat menggunakan AWS CLI atau operasi Amazon Redshift API untuk menjadwalkan pengubahan ukuran. Untuk informasi selengkapnya, lihat create-scheduled-actiondi Referensi AWS CLI Perintah atau CreateScheduledActiondi Referensi API Amazon Redshift.

Snapshot, pulihkan, dan ubah ukuran

Pengubahan ukuran elastis adalah metode tercepat untuk mengubah ukuran cluster Amazon Redshift. Jika pengubahan ukuran elastis bukan pilihan untuk Anda dan Anda memerlukan akses tulis hampir konstan ke klaster Anda, gunakan operasi snapshot dan pulihkan dengan pengubahan ukuran klasik seperti yang dijelaskan di bagian berikut. Pendekatan ini mensyaratkan bahwa setiap data yang ditulis ke cluster sumber setelah snapshot diambil harus disalin secara manual ke cluster target setelah sakelar. Bergantung pada berapa lama salinannya, Anda mungkin perlu mengulanginya beberapa kali sampai Anda memiliki data yang sama di kedua cluster. Kemudian Anda dapat beralih ke cluster target. Proses ini mungkin berdampak negatif pada kueri yang ada sampai kumpulan data lengkap tersedia di kluster target. Namun, ini meminimalkan jumlah waktu yang tidak dapat Anda tulis ke database.

Pendekatan snapshot, restore, dan classic resize menggunakan proses berikut:

  1. Ambil snapshot dari cluster Anda yang ada. Cluster yang ada adalah cluster sumber.

  2. Perhatikan waktu snapshot diambil. Melakukan hal ini berarti Anda nantinya dapat mengidentifikasi titik ketika Anda perlu menjalankan kembali proses ekstrak, bertransaksi, memuat (ETL) untuk memuat data pasca-snapshot apa pun ke dalam basis data target.

  3. Kembalikan snapshot ke cluster baru. Cluster baru ini adalah cluster target. Verifikasi bahwa data sampel ada di cluster target.

  4. Ubah ukuran cluster target. Pilih jenis node baru, jumlah node, dan pengaturan lain untuk cluster target.

  5. Tinjau beban dari proses ETL Anda yang terjadi setelah Anda mengambil snapshot dari cluster sumber. Pastikan untuk memuat ulang data yang sama dalam urutan yang sama ke dalam cluster target. Jika Anda memiliki pemuatan data yang sedang berlangsung, ulangi proses ini beberapa kali hingga data sama di cluster sumber dan target.

  6. Hentikan semua kueri yang berjalan di cluster sumber. Untuk melakukan ini, Anda dapat me-reboot cluster, atau Anda dapat masuk sebagai superuser dan menggunakan perintah PG_CANCEL_BACKEND dan PG_TERMINATE_BACKEND. Mem-boot ulang cluster adalah cara termudah untuk memastikan bahwa cluster tidak tersedia.

  7. Ganti nama cluster sumber. Misalnya, ganti nama dari examplecluster keexamplecluster-source.

  8. Ganti nama cluster target untuk menggunakan nama cluster sumber sebelum mengganti nama. Misalnya, ganti nama cluster target dari sebelumnya menjadi. examplecluster Mulai saat ini, aplikasi apa pun yang menggunakan titik akhir yang berisi examplecluster terhubung ke cluster target.

  9. Hapus kluster sumber setelah Anda beralih ke kluster target, dan verifikasi bahwa semua proses berfungsi seperti yang diharapkan.

Atau, Anda dapat mengganti nama cluster sumber dan target sebelum memuat ulang data ke cluster target. Pendekatan ini berfungsi jika Anda tidak mengharuskan sistem dan laporan dependen apa pun segera diperbarui dengan yang ada di cluster target. Dalam hal ini, langkah 6 bergerak ke akhir proses yang dijelaskan sebelumnya.

Proses rename hanya diperlukan jika Anda ingin aplikasi terus menggunakan endpoint yang sama untuk terhubung ke cluster. Jika Anda tidak memerlukan ini, Anda dapat memperbarui aplikasi apa pun yang terhubung ke cluster untuk menggunakan titik akhir klaster target tanpa mengganti nama cluster.

Ada beberapa manfaat untuk menggunakan kembali nama cluster. Pertama, Anda tidak perlu memperbarui string koneksi aplikasi karena titik akhir tidak berubah, meskipun klaster yang mendasarinya berubah. Kedua, item terkait seperti CloudWatch alarm Amazon dan notifikasi Amazon Simple Notification Service (Amazon SNS) terkait dengan nama cluster. Ikatan ini berarti Anda dapat terus menggunakan alarm dan notifikasi yang sama dengan yang Anda atur untuk cluster. Penggunaan berkelanjutan ini terutama menjadi perhatian di lingkungan produksi di mana Anda menginginkan fleksibilitas untuk mengubah ukuran cluster tanpa mengonfigurasi ulang item terkait, seperti alarm dan notifikasi.