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

Migrasi ke Aurora Serverless v2

Untuk mengonversi klaster DB yang ada untuk menggunakan Aurora Serverless v2, Anda dapat melakukan hal berikut:

Saat klaster yang ditingkatkan menjalankan versi mesin yang sesuai seperti yang tercantum dalam Persyaratan dan batasan untuk Aurora Serverless v2, Anda dapat mulai menambahkan instans DB Aurora Serverless v2 ke dalamnya. Instans DB pertama yang Anda tambahkan ke klaster yang ditingkatkan harus berupa instans DB terprovisi. Kemudian, Anda dapat mengalihkan pemrosesan untuk beban kerja tulis, beban kerja baca, atau keduanya ke instans DB Aurora Serverless v2.

Meningkatkan atau beralih dari klaster yang ada ke Aurora Serverless v2

Jika klaster terprovisi memiliki versi mesin yang mendukung Aurora Serverless v2, peralihan ke Aurora Serverless v2 tidak memerlukan peningkatan. Dalam hal ini, Anda dapat menambahkan instans DB Aurora Serverless v2 ke klaster asli Anda. Anda dapat beralih dari klaster ini ke semua instans DB Aurora Serverless v2. Anda juga dapat menggunakan kombinasi instans DB Aurora Serverless v2 dan instans DB terprovisi di klaster DB yang sama. Untuk versi mesin Aurora yang mendukung Aurora Serverless v2, lihat Daerah yang Didukung dan mesin Aurora DB untuk Aurora Serverless v2.

Jika Anda menjalankan versi mesin yang lebih rendah yang tidak mendukung Aurora Serverless v2, Anda perlu mengambil langkah-langkah umum ini:

Peningkatan dari Aurora Serverless v1 ke Aurora Serverless v2 memerlukan pembuatan klaster terprovisi sebagai langkah perantara. Kemudian, Anda melakukan langkah peningkatan yang sama seperti ketika Anda memulai dengan klaster terprovisi.

Jalur peningkatan untuk klaster yang kompatibel dengan MySQL untuk menggunakan Aurora Serverless v2

Jika klaster asli Anda menjalankan Aurora MySQL, pilih prosedur yang sesuai tergantung pada versi mesin dan mode mesin klaster Anda.

Jalur peningkatan untuk klaster yang kompatibel dengan PostgreSQL untuk menggunakan Aurora Serverless v2

Jika klaster asli Anda menjalankan Aurora PostgreSQL, pilih prosedur yang sesuai tergantung pada versi mesin dan mode mesin klaster Anda.

Beralih dari klaster terprovisi ke Aurora Serverless v2

Untuk beralih dari klaster terprovisi ke Aurora Serverless v2, ikuti langkah-langkah berikut:

AWS CLI Contoh berikut menunjukkan proses peralihan menggunakan klaster yang disediakan yang menjalankan Aurora MySQL versi 3.02.0. Klasternya bernama mysql-80. Klaster ini dimulai dengan dua instans DB terprovisi bernama provisioned-instance-1 dan provisioned-instance-2, satu penulis dan satu pembaca. Keduanya menggunakan kelas instans DB db.r6g.large.

$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 \
  --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' --output text
mysql-80
provisioned-instance-2     False
provisioned-instance-1     True

$ aws rds describe-db-instances --db-instance-identifier provisioned-instance-1 \
  --output text --query '*[].[DBInstanceIdentifier,DBInstanceClass]'
provisioned-instance-1     db.r6g.large

$ aws rds describe-db-instances --db-instance-identifier provisioned-instance-2 \
  --output text --query '*[].[DBInstanceIdentifier,DBInstanceClass]'
provisioned-instance-2     db.r6g.large

Kita membuat tabel dengan beberapa data. Dengan demikian, kita dapat mengonfirmasi bahwa data ini dan operasi klaster sama sebelum dan setelah switchover.

mysql> create database serverless_v2_demo;
mysql> create table serverless_v2_demo.demo (s varchar(128));
mysql> insert into serverless_v2_demo.demo values ('This cluster started with a provisioned writer.');
Query OK, 1 row affected (0.02 sec)

Pertama, kita menambahkan rentang kapasitas ke klaster ini. Jika tidak, kita akan mendapatkan kesalahan saat menambahkan instans DB Aurora Serverless v2 apa pun ke klaster ini. Jika kita menggunakan Konsol Manajemen AWS untuk prosedur ini, langkah itu otomatis ketika kita menambahkan instance Aurora Serverless v2 DB pertama.

$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-1 \
  --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql

An error occurred (InvalidDBClusterStateFault) when calling the CreateDBInstance operation:
Set the Serverless v2 scaling configuration on the parent DB cluster before creating a Serverless v2 DB instance.

$ # The blank ServerlessV2ScalingConfiguration attribute confirms that the cluster doesn't have a capacity range set yet.
$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 --query 'DBClusters[*].ServerlessV2ScalingConfiguration'
[]

$ aws rds modify-db-cluster --db-cluster-identifier mysql-80 \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16
{
  "DBClusterIdentifier": "mysql-80",
  "ServerlessV2ScalingConfiguration": {
    "MinCapacity": 0.5,
    "MaxCapacity": 16
  }
}

Kita membuat dua pembaca Aurora Serverless v2 untuk menggantikan instans DB asli. Kita melakukannya dengan menentukan kelas instans DB db.serverless untuk instans DB baru.

$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-1 --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql
{
  "DBInstanceIdentifier": "serverless-v2-instance-1",
  "DBClusterIdentifier": "mysql-80",
  "DBInstanceClass": "db.serverless",
  "DBInstanceStatus": "creating"
}

$ aws rds create-db-instance --db-instance-identifier serverless-v2-instance-2 \
  --db-cluster-identifier mysql-80 --db-instance-class db.serverless --engine aurora-mysql
{
  "DBInstanceIdentifier": "serverless-v2-instance-2",
  "DBClusterIdentifier": "mysql-80",
  "DBInstanceClass": "db.serverless",
  "DBInstanceStatus": "creating"
}

$ # Wait for both DB instances to finish being created before proceeding.
$ aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-1 && \
  aws rds wait db-instance-available --db-instance-identifier serverless-v2-instance-2

Kita melakukan failover untuk menjadikan salah satu instans DB Aurora Serverless v2 sebagai penulis baru untuk klaster.

$ aws rds failover-db-cluster --db-cluster-identifier mysql-80 \
  --target-db-instance-identifier serverless-v2-instance-1
{
  "DBClusterIdentifier": "mysql-80",
  "DBClusterMembers": [
    {
      "DBInstanceIdentifier": "serverless-v2-instance-1",
      "IsClusterWriter": false,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    },
    {
      "DBInstanceIdentifier": "serverless-v2-instance-2",
      "IsClusterWriter": false,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    },
    {
      "DBInstanceIdentifier": "provisioned-instance-2",
      "IsClusterWriter": false,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    },
    {
      "DBInstanceIdentifier": "provisioned-instance-1",
      "IsClusterWriter": true,
      "DBClusterParameterGroupStatus": "in-sync",
      "PromotionTier": 1
    }
  ],
  "Status": "available"
}

Perlu beberapa detik agar perubahan tersebut diterapkan. Pada saat itu, kita akan memiliki satu penulis Aurora Serverless v2 dan satu pembaca Aurora Serverless v2. Jadi, kita tidak memerlukan instans DB asli terprovisi mana pun.

$ aws rds describe-db-clusters --db-cluster-identifier mysql-80 \
  --query '*[].[DBClusterIdentifier,DBClusterMembers[*].[DBInstanceIdentifier,IsClusterWriter]]' \
  --output text
mysql-80
serverless-v2-instance-1        True
serverless-v2-instance-2        False
provisioned-instance-2          False
provisioned-instance-1          False

Langkah terakhir dalam prosedur switchover adalah menghapus kedua instans DB terprovisi.

$ aws rds delete-db-instance --db-instance-identifier provisioned-instance-2 --skip-final-snapshot
{
  "DBInstanceIdentifier": "provisioned-instance-2",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceClass": "db.r6g.large"
}

$ aws rds delete-db-instance --db-instance-identifier provisioned-instance-1 --skip-final-snapshot
{
  "DBInstanceIdentifier": "provisioned-instance-1",
  "DBInstanceStatus": "deleting",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.02.0",
  "DBInstanceClass": "db.r6g.large"
}

Sebagai pemeriksaan terakhir, kita akan mengonfirmasi bahwa tabel asli dapat diakses dan dapat ditulis dari instans DB penulis Aurora Serverless v2.

mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s                                                 |
+---------------------------------------------------+
| This cluster started with a provisioned writer.   |
+---------------------------------------------------+
1 row in set (0.00 sec)

mysql> insert into serverless_v2_demo.demo values ('And it finished with a Serverless v2 writer.');
Query OK, 1 row affected (0.01 sec)

mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s                                                 |
+---------------------------------------------------+
| This cluster started with a provisioned writer.   |
| And it finished with a Serverless v2 writer.      |
+---------------------------------------------------+
2 rows in set (0.01 sec)

Kita juga menghubungkan ke instans DB pembaca Aurora Serverless v2 dan mengonfirmasi bahwa data yang baru ditulis juga tersedia di sana.

mysql> select * from serverless_v2_demo.demo;
+---------------------------------------------------+
| s                                                 |
+---------------------------------------------------+
| This cluster started with a provisioned writer.   |
| And it finished with a Serverless v2 writer.      |
+---------------------------------------------------+
2 rows in set (0.01 sec)

Perbandingan Aurora Serverless v2 dan Aurora Serverless v1

Jika Anda sudah menggunakan Aurora Serverless v1, Anda dapat mempelajari perbedaan besar antara Aurora Serverless v1 dan Aurora Serverless v2. Perbedaan arsitektur, seperti dukungan untuk instans DB pembaca, menyediakan jenis kasus penggunaan baru.

Anda dapat menggunakan tabel berikut untuk membantu memahami perbedaan paling penting antara Aurora Serverless v2 dan Aurora Serverless v1.

Perbandingan persyaratan Aurora Serverless v2 dan Aurora Serverless v1

Tabel berikut merangkum persyaratan yang berbeda untuk menjalankan basis data Anda menggunakan Aurora Serverless v2 atau Aurora Serverless v1. Aurora Serverless v2 menawarkan versi mesin DB Aurora MySQL dan Aurora PostgreSQL yang lebih tinggi daripada Aurora Serverless v1.

Perbandingan penskalaan dan ketersediaan Aurora Serverless v2 dan Aurora Serverless v1

Tabel berikut merangkum perbedaan antara Aurora Serverless v2 dan Aurora Serverless v1 dari segi skalabilitas dan ketersediaan.

Penskalaan Aurora Serverless v2 lebih responsif, lebih terperinci, dan tidak terlalu mengganggu daripada penskalaan Aurora Serverless v1. Aurora Serverless v2 dapat diskalakan dengan mengubah ukuran instans DB dan dengan menambahkan lebih banyak instans DB ke klaster DB. Hal ini juga dapat skala dengan menambahkan cluster lain Wilayah AWS ke database global Aurora. Sebaliknya, Aurora Serverless v1 diskalakan hanya dengan menambahkan atau mengurangi kapasitas penulis. Semua komputasi untuk klaster Aurora Serverless v1 berjalan di satu Zona Ketersediaan dan satu Wilayah AWS.

Perbandingan dukungan fitur Aurora Serverless v2 dan Aurora Serverless v1

Tabel berikut merangkum hal ini:

Aurora Serverless v2 mencakup banyak fitur dari klaster terprovisi yang tidak tersedia untuk Aurora Serverless v1.

Mengadaptasi kasus penggunaan Aurora Serverless v1 ke Aurora Serverless v2

Bergantung pada kasus penggunaan Anda untuk Aurora Serverless v1, Anda dapat menyesuaikan pendekatan tersebut untuk memanfaatkan fitur Aurora Serverless v2 sebagai berikut.

Misalkan Anda memiliki klaster Aurora Serverless v1 yang diberi beban ringan dan prioritas Anda adalah menjaga ketersediaan yang berkelanjutan sambil meminimalkan biaya. Dengan Aurora Serverless v2, Anda dapat mengonfigurasi pengaturan ACU minimum yang lebih kecil sebesar 0,5, dibandingkan dengan minimal 1 ACU untuk Aurora Serverless v1. Anda dapat meningkatkan ketersediaan dengan membuat konfigurasi Multi-AZ, dengan instans DB pembaca juga memiliki minimal 0,5 ACUs.

Misalkan Anda memiliki klaster Aurora Serverless v1 yang Anda gunakan dalam skenario pengembangan dan pengujian. Dalam hal ini, biaya juga merupakan prioritas tinggi tetapi cluster tidak perlu tersedia setiap saat. Aurora Serverless v2dapat secara otomatis menjeda setiap instance saat benar-benar menganggur. Anda melakukannya dengan menentukan kapasitas minimum 0 ACUs untuk cluster, seperti yang dijelaskan dalamPenskalaan ke Nol ACUs dengan jeda otomatis dan lanjutkan Aurora Serverless v2. Anda juga dapat menghentikan cluster secara manual saat tidak diperlukan, dan memulainya saat waktunya untuk siklus pengujian atau pengembangan berikutnya.

Misalkan Anda memiliki klaster Aurora Serverless v1 dengan beban kerja yang berat. Sebuah klaster setara yang menggunakan Aurora Serverless v2 dapat diskalakan dengan lebih banyak granularitas. Misalnya, Aurora Serverless v1 skala dengan menggandakan kapasitas, misalnya dari 64 menjadi 128 ACUs. Sebaliknya, instans Aurora Serverless v2 DB Anda dapat menskalakan dalam peningkatan 0,5-ACU.

Misalkan beban kerja Anda membutuhkan kapasitas total yang lebih tinggi daripada yang tersedia di Aurora Serverless v1. Anda dapat menggunakan beberapa instans DB pembaca Aurora Serverless v2 untuk mengambil alih bagian beban kerja yang sarat baca dari instans DB penulis. Anda juga dapat membagi beban kerja yang sarat baca di antara beberapa instans DB pembaca.

Untuk beban kerja sarat tulis, Anda dapat mengonfigurasi klaster dengan instans DB besar terprovisi sebagai penulis. Anda dapat melakukannya bersama satu atau beberapa instans DB pembaca Aurora Serverless v2.

Peningkatan dari klaster Aurora Serverless v1 ke Aurora Serverless v2

Proses meningkatkan klaster DB dari Aurora Serverless v1 ke Aurora Serverless v2 memiliki beberapa langkah. Hal ini karena Anda tidak dapat mengonversi langsung dari Aurora Serverless v1 ke Aurora Serverless v2. Selalu ada langkah perantara yang memerlukan konversi klaster DB Aurora Serverless v1 ke klaster terprovisi.

Klaster DB yang kompatibel dengan Aurora MySQL

Anda dapat mengonversi cluster Aurora Serverless v1 DB Anda ke kluster DB yang disediakan, lalu menggunakan blue/green penerapan untuk memutakhirkannya dan mengubahnya menjadi cluster DB. Aurora Serverless v2 Kami merekomendasikan prosedur ini untuk lingkungan produksi. Untuk informasi selengkapnya, lihat Menggunakan Amazon Aurora Blue/Green Deployment untuk pembaruan database.

Klaster DB yang kompatibel dengan Aurora PostgreSQL

Anda dapat mengonversi cluster Aurora Serverless v1 DB Anda ke kluster DB yang disediakan, lalu menggunakan blue/green penerapan untuk memutakhirkannya dan mengubahnya menjadi cluster DB. Aurora Serverless v2 Kami merekomendasikan prosedur ini untuk lingkungan produksi. Untuk informasi selengkapnya, lihat Menggunakan Amazon Aurora Blue/Green Deployment untuk pembaruan database.

Anda juga dapat memutakhirkan cluster Aurora Serverless v1 DB Anda langsung dari Aurora PostgreSQL versi 11 ke versi 13, mengubahnya menjadi cluster DB yang disediakan, dan kemudian mengonversi cluster yang disediakan menjadi cluster DB. Aurora Serverless v2

Untuk kluster Aurora Serverless v1 DB yang menjalankan Aurora PostgreSQL versi 13, Anda Aurora Serverless v1 mengonversi cluster menjadi kluster DB yang disediakan, lalu mengonversi cluster yang disediakan menjadi cluster DB. Aurora Serverless v2

Bermigrasi dari basis data on-premise ke Aurora Serverless v2

Anda dapat memigrasikan basis data on-premise Anda ke Aurora Serverless v2, seperti halnya dengan Aurora MySQL dan Aurora PostgreSQL terprovisi.