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 cluster DB yang ada untuk digunakan Aurora Serverless v2, Anda dapat melakukan hal berikut:

Saat klaster yang ditingkatkan menjalankan versi mesin yang sesuai seperti yang tercantum dalamPersyaratan dan batasan untuk Aurora Serverless v2, Anda dapat mulai menambahkan Aurora Serverless v2 Contoh DB untuk itu. 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 Aurora Serverless v2 Contoh DB.

Memutakhirkan atau mengalihkan cluster yang ada untuk digunakan Aurora Serverless v2

Jika klaster yang Anda sediakan memiliki versi engine yang mendukung Aurora Serverless v2, beralih ke Aurora Serverless v2 tidak memerlukan upgrade. Dalam hal ini, Anda dapat menambahkan Aurora Serverless v2 Instans DB ke cluster asli Anda. Anda dapat mengganti cluster untuk menggunakan semua Aurora Serverless v2 Contoh DB. Anda juga dapat menggunakan kombinasi Aurora Serverless v2 dan menyediakan instance DB di cluster 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 mengambil langkah-langkah umum ini:

Upgrade dari Aurora Serverless v1 kepada Aurora Serverless v2 melibatkan pembuatan cluster yang disediakan sebagai langkah perantara. Kemudian, Anda melakukan langkah peningkatan yang sama seperti ketika Anda memulai dengan klaster terprovisi.

Tingkatkan jalur untuk kluster SQL yang kompatibel dengan Saya untuk digunakan Aurora Serverless v2

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

Tingkatkan jalur untuk kluster yang SQL kompatibel dengan Postgre untuk digunakan Aurora Serverless v2

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

Beralih dari klaster yang disediakan ke Aurora Serverless v2

Untuk mengganti klaster yang disediakan untuk digunakan Aurora Serverless v2, ikuti langkah-langkah ini:

AWS CLI Contoh berikut menunjukkan proses peralihan menggunakan klaster yang disediakan yang menjalankan Aurora My versi 3.02.0. SQL 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, kami mendapatkan kesalahan saat menambahkan Aurora Serverless v2 Instans DB ke cluster. Jika kita menggunakan AWS Management Console untuk prosedur ini, langkah itu otomatis ketika kita menambahkan yang pertama Aurora Serverless v2 contoh DB.

$ 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
  }
}

Kami membuat dua Aurora Serverless v2 pembaca 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

Kami melakukan failover untuk membuat salah satu Aurora Serverless v2 DB membuat instance penulis baru untuk cluster.

$ 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 memiliki Aurora Serverless v2 Penulis dan seorang Aurora Serverless v2 pembaca. 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, kami mengonfirmasi bahwa tabel asli dapat diakses dan dapat ditulis dari Aurora Serverless v2 penulis contoh DB.

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)

Kami juga terhubung ke Aurora Serverless v2 pembaca DB instance dan konfirmasikan 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 and Aurora Serverless v1

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

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

Perbandingan Aurora Serverless v2 and Aurora Serverless v1 persyaratan

Tabel berikut merangkum persyaratan yang berbeda untuk menjalankan database Anda menggunakan Aurora Serverless v2 atau Aurora Serverless v1. Aurora Serverless v2 menawarkan versi yang lebih tinggi dari mesin Aurora My dan SQL Aurora Postgre DB SQL Aurora Serverless v1 tidak.

Perbandingan Aurora Serverless v2 and Aurora Serverless v1 penskalaan dan ketersediaan

Tabel berikut merangkum perbedaan antara Aurora Serverless v2 and Aurora Serverless v1 untuk skalabilitas dan ketersediaan.

Aurora Serverless v2 penskalaan lebih responsif, lebih terperinci, dan tidak terlalu mengganggu daripada penskalaan Aurora Serverless v1. Aurora Serverless v2 dapat menskalakan keduanya dengan mengubah ukuran instans DB dan dengan menambahkan lebih banyak instance DB ke cluster DB. Hal ini juga dapat skala dengan menambahkan cluster lain Wilayah AWS ke database global Aurora. Sebaliknya, Aurora Serverless v1 hanya menskalakan dengan menambah atau mengurangi kapasitas penulis. Semua komputasi untuk Aurora Serverless v1 cluster berjalan dalam satu Availability Zone dan satu Wilayah AWS.

Perbandingan Aurora Serverless v2 and Aurora Serverless v1 dukungan fitur

Tabel berikut merangkum hal ini:

Aurora Serverless v2 menyertakan banyak fitur dari kluster yang disediakan yang tidak tersedia untuk Aurora Serverless v1.

Beradaptasi Aurora Serverless v1 menggunakan kasus untuk Aurora Serverless v2

Tergantung pada kasus penggunaan Anda untuk Aurora Serverless v1, Anda mungkin menyesuaikan pendekatan itu untuk memanfaatkan Aurora Serverless v2 fitur sebagai berikut.

Misalkan Anda memiliki Aurora Serverless v1 cluster yang dimuat ringan dan prioritas Anda adalah menjaga ketersediaan berkelanjutan sambil meminimalkan biaya. Dengan Aurora Serverless v2, Anda dapat mengonfigurasi ACU pengaturan minimum yang lebih kecil 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,5ACUs.

Misalkan Anda memiliki Aurora Serverless v1 cluster yang Anda gunakan dalam skenario pengembangan dan pengujian. Dalam hal ini, biaya juga merupakan prioritas tinggi, tetapi klaster tidak perlu tersedia setiap saat. Saat ini, Aurora Serverless v2 tidak secara otomatis berhenti saat cluster benar-benar menganggur. Sebagai gantinya, Anda dapat menghentikan klaster secara manual saat tidak diperlukan, dan memulainya saat waktunya untuk siklus pengujian atau pengembangan berikutnya.

Misalkan Anda memiliki Aurora Serverless v1 cluster dengan beban kerja yang berat. Cluster yang setara menggunakan Aurora Serverless v2 dapat menskalakan dengan lebih granularitas. Misalnya, Aurora Serverless v1 skala dengan menggandakan kapasitas, misalnya dari 64 menjadi 128ACUs. Sebaliknya, Anda Aurora Serverless v2 Instans DB dapat menskalakan dengan ACU peningkatan 0,5.

Misalkan beban kerja Anda membutuhkan kapasitas total yang lebih tinggi daripada yang tersedia di Aurora Serverless v1. Anda dapat menggunakan beberapa Aurora Serverless v2 instans DB pembaca untuk menurunkan bagian beban kerja yang intensif 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 lebih Aurora Serverless v2 contoh DB pembaca.

Upgrade dari sebuah Aurora Serverless v1 cluster ke Aurora Serverless v2

Proses upgrade cluster DB dari Aurora Serverless v1 kepada Aurora Serverless v2 memiliki beberapa langkah. Itu karena Anda tidak dapat mengonversi langsung dari Aurora Serverless v1 kepada Aurora Serverless v2. Selalu ada langkah perantara yang melibatkan konversi Aurora Serverless v1 Cluster DB ke cluster yang disediakan.

Aurora My SQL —cluster DB yang kompatibel

Anda dapat mengonversi Aurora Serverless v1 Cluster DB ke cluster DB yang disediakan, lalu gunakan penerapan biru/hijau untuk memutakhirkannya dan mengubahnya menjadi Aurora Serverless v2 klaster DB. Kami merekomendasikan prosedur ini untuk lingkungan produksi. Untuk informasi selengkapnya, lihat Menggunakan Amazon RDS Blue/Green Deployment untuk pembaruan database.

Aurora SQL Postgre —cluster DB yang kompatibel

Anda dapat mengonversi Aurora Serverless v1 Cluster DB ke cluster DB yang disediakan, lalu gunakan penerapan biru/hijau untuk memutakhirkannya dan mengubahnya menjadi Aurora Serverless v2 klaster DB. Kami merekomendasikan prosedur ini untuk lingkungan produksi. Untuk informasi selengkapnya, lihat Menggunakan Amazon RDS Blue/Green Deployment untuk pembaruan database.

Anda juga dapat meng-upgrade Aurora Serverless v1 Cluster DB langsung dari Aurora Postgre SQL versi 11 ke versi 13, mengubahnya menjadi cluster DB yang disediakan, dan kemudian mengonversi cluster yang disediakan menjadi Aurora Serverless v2 klaster DB.

Untuk Aurora Serverless v1 Cluster DB yang menjalankan Aurora SQL Postgre versi 13, Anda mengonversi Aurora Serverless v1 cluster ke cluster DB yang disediakan, dan kemudian mengonversi cluster yang disediakan menjadi Aurora Serverless v2 klaster DB.

Migrasi dari database lokal ke Aurora Serverless v2

Anda dapat memigrasikan database lokal Anda ke Aurora Serverless v2, sama seperti Aurora My dan Aurora Postgre yang disediakan. SQL SQL