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

Praktik terbaik untuk Amazon RDS

Pelajari praktik terbaik untuk bekerja dengan AmazonRDS. Saat praktik terbaik yang baru diidentifikasi, kami akan terus memperbarui bagian ini.

Pedoman operasional RDS dasar Amazon

Berikut ini adalah pedoman operasional dasar yang harus diikuti setiap orang saat bekerja dengan AmazonRDS. Perhatikan bahwa Perjanjian Tingkat RDS Layanan Amazon mengharuskan Anda mengikuti panduan ini:

RAMRekomendasi instans DB

Praktik terbaik RDS kinerja Amazon adalah mengalokasikan cukup RAM sehingga set kerja Anda berada hampir sepenuhnya dalam memori. Set kerja adalah data dan indeks yang sering Anda gunakan pada instans. Makin banyak Anda menggunakan instans DB, makin banyak set kerja yang akan tumbuh.

Untuk mengetahui apakah set kerja Anda hampir semuanya ada dalam memori, periksa IOPS metrik Baca (menggunakan Amazon CloudWatch) saat instans DB sedang dimuat. Nilai Read IOPS harus kecil dan stabil. Dalam beberapa kasus, meningkatkan kelas instans DB ke kelas dengan lebih banyak RAM menghasilkan penurunan dramatis dalam BacaIOPS. Dalam kasus ini, set kerja Anda hampir tidak seluruhnya berada di memori. Terus tingkatkan hingga Read IOPS tidak lagi turun secara dramatis setelah operasi penskalaan, atau Read IOPS dikurangi menjadi jumlah yang sangat kecil. Untuk informasi tentang pemantauan metrik instans DB, lihat Melihat metrik di konsol Amazon RDS.

AWS driver basis data

Kami merekomendasikan AWS rangkaian driver untuk konektivitas aplikasi. Driver telah dirancang untuk memberikan dukungan untuk waktu peralihan dan failover yang lebih cepat, dan otentikasi dengan AWS Secrets Manager, AWS Identity and Access Management (IAM), dan Identitas Federasi. Bagian AWS driver mengandalkan pemantauan status instans DB dan menyadari topologi instance untuk menentukan penulis baru. Pendekatan ini mengurangi waktu peralihan dan failover menjadi satu digit detik, dibandingkan dengan puluhan detik untuk driver open-source.

Saat fitur layanan baru diperkenalkan, tujuan AWS suite driver adalah memiliki dukungan bawaan untuk fitur layanan ini.

Untuk informasi selengkapnya, lihat Menghubungkan ke instans DB dengan driver AWS.

Menggunakan Pemantauan yang Ditingkatkan untuk mengidentifikasi masalah sistem operasi

Saat Enhanced Monitoring diaktifkan, Amazon RDS menyediakan metrik secara real time untuk sistem operasi (OS) tempat instans DB Anda berjalan. Anda dapat melihat metrik instans DB menggunakan konsol tersebut. Anda juga dapat menggunakan JSON output Enhanced Monitoring dari Amazon CloudWatch Logs dalam sistem pemantauan pilihan Anda. Untuk informasi selengkapnya tentang Pemantauan yang Ditingkatkan, lihat Memantau metrik OS dengan Pemantauan yang Ditingkatkan.

Menggunakan metrik untuk mengidentifikasi masalah performa

Untuk mengidentifikasi masalah kinerja yang disebabkan oleh sumber daya yang tidak mencukupi dan kemacetan umum lainnya, Anda dapat memantau metrik yang tersedia untuk instans Amazon DB Anda. RDS

Melihat metrik performa

Anda harus memantau metrik performa secara rutin untuk mengetahui nilai rata-rata, maksimum, dan minimum dalam berbagai rentang waktu. Sehingga Anda dapat mengidentifikasi saat performa menurun. Anda juga dapat mengatur CloudWatch alarm Amazon untuk ambang metrik tertentu sehingga Anda diberi tahu jika mereka tercapai.

Untuk memecahkan masalah performa, penting untuk memahami performa dasar sistem. Saat Anda menyiapkan instans DB dan menjalankannya dengan beban kerja umum, catat nilai rata-rata, maksimum, dan minimum dari semua metrik performa. Lakukan hal tersebut pada sejumlah interval yang berbeda (misalnya, satu jam, 24 jam, satu minggu, dua minggu). Tindakan ini dapat memberi Anda gambaran tentang kondisi normal. Sehingga membantu mendapatkan perbandingan untuk jam sibuk dan tidak sibuk. Kemudian, Anda dapat menggunakan informasi ini untuk mengidentifikasi saat performa turun di bawah tingkat standar.

Jika Anda menggunakan klaster DB Multi-AZ, pantau selisih waktu antara transaksi terbaru pada instans DB penulis dan transaksi terbaru yang diterapkan pada instans DB pembaca. Selisih ini disebut jeda replika. Untuk informasi selengkapnya, lihat Kelambatan replika dan klaster basis data Multi-AZ.

Anda dapat melihat gabungan Performance Insights dan CloudWatch metrik di dasbor Performance Insights dan memantau instans DB Anda. Untuk menggunakan tampilan pemantauan ini, Wawasan Performa harus diaktifkan untuk instans DB Anda. Untuk informasi tentang tampilan pemantauan ini, lihat Melihat metrik gabungan dengan dasbor Performance Insights.

Anda dapat membuat laporan analisis performa untuk periode waktu tertentu dan melihat wawasan yang diidentifikasi serta rekomendasi untuk menyelesaikan masalah. Untuk informasi selengkapnya, lihat Membuat laporan analisis kinerja di Performance Insights.

Anda juga dapat melihat metrik kinerja menggunakan CLI atauAPI. Untuk informasi selengkapnya, lihat Melihat metrik di konsol Amazon RDS.

Alarm muncul di bagian CloudWatch alarm.

Mengevaluasi metrik performa

Instans DB memiliki sejumlah kategori metrik yang berbeda, dan cara menentukan nilai yang dapat diterima bergantung pada metrik.

Untuk deskripsi individual yang lebih mendetail tentang metrik performa yang tersedia, lihat Memantau metrik RDSAmazon Amazon dengan Amazon CloudWatch.

Secara umum, nilai yang dapat diterima untuk metrik performa bergantung pada seperti apa garis dasar Anda dan apa yang dilakukan aplikasi Anda. Periksa varian yang konsisten atau sedang tren dari garis dasar Anda. Informasi tentang jenis metrik khusus sebagai berikut:

Untuk masalah pada metrik performa, langkah pertama untuk meningkatkan performa adalah menyetel kueri yang paling sering digunakan dan paling menghabiskan biaya. Setel kueri tersebut untuk melihat apakah langkah ini dapat menurunkan tekanan pada sumber daya sistem. Untuk informasi selengkapnya, lihat Menyetel kueri.

Jika kueri Anda disetel dan masalah tetap ada, pertimbangkan untuk memutakhirkan Amazon Anda. RDS DB Anda dapat memutakhirkannya ke satu dengan lebih banyak sumber daya (CPURAM,, ruang disk, bandwidth jaringan, kapasitas I/O) yang terkait dengan masalah tersebut.

Menyetel kueri

Salah satu cara terbaik untuk meningkatkan performa instans DB adalah dengan menyetel kueri yang paling sering digunakan dan paling sarat sumber daya. Di sini, Anda menyetelnya agar dapat dijalankan dengan biaya yang lebih terjangkau. Untuk informasi tentang peningkatan kueri, gunakan sumber daya berikut:

Praktik terbaik untuk bekerja dengan My SQL

Kedua ukuran tabel dan jumlah tabel dalam SQL database Saya dapat mempengaruhi kinerja.

Ukuran tabel

Biasanya, kendala sistem operasi pada ukuran file menentukan ukuran tabel maksimum efektif untuk database Saya. SQL Jadi, batas-batas biasanya tidak ditentukan oleh SQL kendala internalKu.

Pada instance My SQL DB, hindari tabel di database Anda yang tumbuh terlalu besar. Meskipun batas penyimpanan umum adalah 64 TiB, batas penyimpanan yang disediakan membatasi ukuran maksimum SQL file tabel Saya hingga 16 TiB. Partisi tabel besar Anda sehingga ukuran file berada di bawah batas 16 TiB. Pendekatan ini juga dapat meningkatkan performa dan waktu pemulihan. Untuk informasi selengkapnya, lihat Batas ukuran SQL file saya di Amazon RDS.

Tabel yang sangat besar (berukuran lebih dari 100 GB) dapat berdampak negatif pada kinerja untuk membaca dan menulis (termasuk DML pernyataan dan terutama DDL pernyataan). Indeks pada tabel besar dapat secara signifikan meningkatkan kinerja pilih, tetapi mereka juga dapat menurunkan kinerja pernyataan. DML DDLpernyataan, sepertiALTER TABLE, dapat secara signifikan lebih lambat untuk tabel besar karena operasi tersebut mungkin sepenuhnya membangun kembali tabel dalam beberapa kasus. DDLPernyataan ini mungkin mengunci tabel selama durasi operasi.

Jumlah memori yang dibutuhkan oleh My SQL untuk membaca dan menulis tergantung pada tabel yang terlibat dalam operasi. Ini adalah praktik terbaik untuk memiliki setidaknya cukup RAM untuk menahan indeks tabel yang digunakan secara aktif. Untuk menemukan sepuluh tabel dan indeks terbesar dalam basis data, gunakan kueri berikut:

select table_schema, TABLE_NAME, dat, idx from 
(SELECT table_schema, TABLE_NAME, 
       ( data_length ) / 1024 / 1024 as dat,
       ( index_length ) / 1024 / 1024 as idx
FROM information_schema.TABLES
order by 3 desc ) a
order by 3 desc 
limit 10;

Jumlah tabel

Sistem file yang mendasarinya mungkin memiliki batas jumlah file yang mewakili tabel. Namun, My tidak SQL memiliki batasan jumlah tabel. Meskipun demikian, jumlah total tabel di mesin penyimpanan My SQL InnoDB dapat berkontribusi pada penurunan kinerja, terlepas dari ukuran tabel tersebut. Untuk membatasi dampak sistem operasi, Anda dapat membagi tabel di beberapa database dalam instance My SQL DB yang sama. Tindakan tersebut dapat membatasi jumlah file dalam direktori, tetapi tidak akan menyelesaikan masalah secara keseluruhan.

Ketika ada penurunan kinerja karena sejumlah besar tabel (lebih dari 10 ribu), itu disebabkan oleh Saya SQL bekerja dengan file penyimpanan, termasuk membuka dan menutupnya. Untuk mengatasi masalah ini, Anda dapat meningkatkan ukuran parameter table_open_cache dan table_definition_cache. Namun, meningkatkan nilai parameter tersebut mungkin secara signifikan meningkatkan jumlah memori yang saya SQL gunakan, dan bahkan mungkin menggunakan semua memori yang tersedia. Untuk informasi selengkapnya, lihat Cara Saya SQL Membuka dan Menutup Tabel di SQL Dokumentasi Saya.

Selain itu, terlalu banyak tabel dapat secara signifikan mempengaruhi waktu SQL startup saya. Baik shutdown bersih dan restart dan pemulihan kerusakan dapat terpengaruh, terutama dalam versi sebelum My SQL 8.0.

Kami merekomendasikan total kurang dari 10.000 tabel di semua basis data dalam instans DB. Untuk kasus penggunaan dengan sejumlah besar tabel dalam SQL database Saya, lihat One Million Tables in My SQL 8.0.

Mesin penyimpanan

Fitur point-in-time pemulihan dan pemulihan snapshot Amazon RDS for My SQL memerlukan mesin penyimpanan yang dapat dipulihkan dengan crash. Fitur ini hanya didukung untuk mesin penyimpanan InnoDB. Meskipun My SQL mendukung beberapa mesin penyimpanan dengan berbagai kemampuan, tidak semuanya dioptimalkan untuk pemulihan kerusakan dan daya tahan data. Misalnya, mesin ISAM penyimpanan Saya tidak mendukung pemulihan kerusakan yang andal dan mungkin mencegah point-in-time pemulihan atau pemulihan snapshot berfungsi sebagaimana dimaksud. Hal ini dapat mengakibatkan data hilang atau rusak ketika My SQL dimulai ulang setelah crash.

InnoDB adalah mesin penyimpanan yang direkomendasikan dan didukung untuk instans SQL DB Saya di Amazon. RDS Instance InnoDB juga dapat dimigrasikan ke Aurora, sementara instans ISAM Saya tidak dapat dimigrasikan. Namun, My ISAM berkinerja lebih baik daripada InnoDB jika Anda membutuhkan kemampuan pencarian teks lengkap yang intens. Jika Anda masih memilih untuk menggunakan My ISAM with AmazonRDS, mengikuti langkah-langkah yang diuraikan Pencadangan otomatis dengan mesin penyimpanan Saya yang tidak didukung SQL dapat membantu dalam skenario tertentu untuk fungsionalitas pemulihan snapshot.

Jika Anda ingin mengonversi ISAM tabel Saya yang ada ke tabel InnoDB, Anda dapat menggunakan proses yang diuraikan dalam Mengonversi Tabel dari Saya ke ISAM InnoDB di dokumentasi Saya. SQL My ISAM dan InnoDB memiliki kekuatan dan kelemahan yang berbeda, jadi Anda harus sepenuhnya mengevaluasi dampak dari membuat peralihan ini pada aplikasi Anda sebelum melakukannya.

Selain itu, Federated Storage Engine saat ini tidak didukung oleh Amazon RDS untuk MySQL.

Praktik terbaik untuk menggunakan MariaDB

Ukuran tabel dan jumlah tabel dalam basis data MariaDB dapat memengaruhi performa.

Ukuran tabel

Biasanya, batasan sistem operasi pada ukuran file menentukan ukuran tabel maksimum yang efektif untuk basis data MariaDB. Jadi, batasannya biasanya tidak ditentukan oleh batasan MariaDB internal.

Untuk instans DB MariaDB, hindari tabel di basis data Anda yang tumbuh terlalu besar. Meskipun batas penyimpanan umum adalah 64 TiB, batas penyimpanan yang tersedia membatasi ukuran maksimum file tabel MariaDB hingga 16 TiB. Partisi tabel besar Anda sehingga ukuran file berada di bawah batas 16 TiB. Pendekatan ini juga dapat meningkatkan performa dan waktu pemulihan.

Tabel yang sangat besar (berukuran lebih dari 100 GB) dapat berdampak negatif pada kinerja untuk membaca dan menulis (termasuk DML pernyataan dan terutama DDL pernyataan). Indeks pada tabel besar dapat secara signifikan meningkatkan kinerja pilih, tetapi mereka juga dapat menurunkan kinerja pernyataan. DML DDLpernyataan, sepertiALTER TABLE, dapat secara signifikan lebih lambat untuk tabel besar karena operasi tersebut mungkin sepenuhnya membangun kembali tabel dalam beberapa kasus. DDLPernyataan ini mungkin mengunci tabel selama durasi operasi.

Jumlah memori yang diperlukan oleh MariaDB untuk baca dan tulis tergantung pada tabel yang terlibat dalam operasi. Ini adalah praktik terbaik untuk memiliki setidaknya cukup RAM untuk menahan indeks tabel yang digunakan secara aktif. Untuk menemukan sepuluh tabel dan indeks terbesar dalam basis data, gunakan kueri berikut:

select table_schema, TABLE_NAME, dat, idx from 
(SELECT table_schema, TABLE_NAME, 
       ( data_length ) / 1024 / 1024 as dat,
       ( index_length ) / 1024 / 1024 as idx
FROM information_schema.TABLES
order by 3 desc ) a
order by 3 desc 
limit 10;

Jumlah tabel

Sistem file yang mendasarinya mungkin memiliki batas jumlah file yang mewakili tabel. Namun, MariaDB tidak memiliki batasan jumlah tabel. Meskipun demikian, total jumlah tabel dalam mesin penyimpanan MariaDB InnoDB dapat berkontribusi pada penurunan performa, terlepas dari ukuran tabel tersebut. Untuk membatasi dampak sistem operasi, Anda dapat memisahkan tabel di beberapa basis data dalam instans DB MariaDB yang sama. Tindakan tersebut dapat membatasi jumlah file dalam direktori, tetapi tidak menyelesaikan masalah secara keseluruhan.

Penurunan performa karena sejumlah besar tabel (lebih dari 10.000) disebabkan oleh MariaDB yang bekerja dengan file penyimpanan. Pekerjaan ini mencakup pembukaan dan penutupan file penyimpanan MariaDB. Untuk mengatasi masalah ini, Anda dapat meningkatkan ukuran parameter table_open_cache dan table_definition_cache. Namun, meningkatkan nilai parameter tersebut dapat secara signifikan meningkatkan jumlah penggunaan memori MariaDB. Bahkan mungkin menggunakan semua memori yang tersedia. Untuk informasi selengkapnya, lihat Optimizing table_open_cache dalam dokumentasi MariaDB.

Selain itu, terlalu banyak tabel dapat secara signifikan memengaruhi waktu pemulaian MariaDB. Pematian dan pengaktifan ulang yang bersih dan pemulihan crash dapat terpengaruh. Kami merekomendasikan jumlah total kurang dari sepuluh ribu tabel di semua basis data dalam instans DB.

Mesin penyimpanan

Fitur point-in-time pemulihan dan pemulihan snapshot Amazon RDS untuk MariaDB memerlukan mesin penyimpanan yang dapat dipulihkan dengan crash. Meskipun MariaDB mendukung banyak mesin penyimpanan dengan berbagai kemampuan, tidak semuanya dioptimalkan untuk pemulihan crash dan durabilitas data. Misalnya, meskipun Aria adalah pengganti yang aman untuk MyISAM, itu mungkin masih mencegah point-in-time pemulihan atau pemulihan snapshot berfungsi sebagaimana dimaksud. Hal ini dapat mengakibatkan hilangnya atau rusaknya data ketika MariaDB dimulai ulang setelah terjadi kerusakan. InnoDB adalah mesin penyimpanan yang direkomendasikan dan didukung untuk instans MariaDB DB di Amazon. RDS Jika Anda masih memilih untuk menggunakan Aria dengan AmazonRDS, mengikuti langkah-langkah yang diuraikan Cadangan otomatis dengan mesin penyimpanan MariaDB yang tidak didukung dapat membantu dalam skenario tertentu untuk fungsionalitas pemulihan snapshot.

Jika Anda ingin mengonversi ISAM tabel Saya yang ada ke tabel InnoDB, Anda dapat menggunakan proses yang diuraikan dalam Mengonversi Tabel dari Saya ke ISAM InnoDB di dokumentasi MariaDB. My ISAM dan InnoDB memiliki kekuatan dan kelemahan yang berbeda, jadi Anda harus sepenuhnya mengevaluasi dampak dari membuat peralihan ini pada aplikasi Anda sebelum melakukannya.

Praktik terbaik untuk menggunakan Oracle

Untuk informasi tentang praktik terbaik untuk bekerja dengan Amazon RDS untuk Oracle, lihat Praktik terbaik untuk menjalankan database Oracle di Amazon Web Services.

SEBUAH 2020 AWS Lokakarya virtual termasuk presentasi tentang menjalankan basis data Oracle produksi di Amazon. RDS Video presentasi tersedia di sini:

Praktik terbaik untuk bekerja dengan Postgre SQL

Dari dua area penting di mana Anda dapat meningkatkan kinerja dengan RDS PostgreSQL, salah satunya adalah saat memuat data ke dalam instance DB. Lain adalah ketika menggunakan fitur SQL autovacuum Postgre. Bagian berikut mencakup beberapa praktik yang direkomendasikan untuk kedua area tersebut.

Untuk informasi tentang cara Amazon RDS mengimplementasikan SQL DBA tugas Postgre umum lainnya, lihat. Tugas DBA umum untuk Amazon RDS for PostgreSQL

Memuat data ke dalam instance Postgre DB SQL

Saat memuat data ke instans Amazon RDS untuk Postgre SQL DB, ubah setelan instans DB dan nilai grup parameter DB Anda. Ubah pengaturan dan nilai tersebut untuk memungkinkan pengimporan data yang paling efisien ke instans DB Anda.

Ubah pengaturan instans DB Anda sebagai berikut:

Ubah grup parameter DB Anda untuk menyertakan pengaturan berikut. Selain itu, uji juga pengaturan parameter untuk menemukan pengaturan yang paling efisien untuk instans DB Anda.

Gunakan perintah pg_dump -Fc (terkompresi) atau pg_restore -j (paralel) dengan pengaturan ini.

Setelah operasi pemuatan selesai, pulihkan instans DB dan parameter DB Anda ke pengaturan normalnya.

Bekerja dengan fitur autovacuum Postgre SQL

Fitur autovacuum untuk SQL database Postgre adalah fitur yang sangat kami sarankan Anda gunakan untuk menjaga kesehatan instans Postgre DB Anda. SQL Autovacuum mengotomatiskan eksekusi VACUUM dan ANALYZE perintah Menggunakan autovacuum diperlukan oleh Postgre, SQL tidak dipaksakan oleh AmazonRDS, dan penggunaannya sangat penting untuk kinerja yang baik. Fitur ini diaktifkan secara default untuk semua instans Amazon baru RDS untuk Postgre SQL DB, dan parameter konfigurasi terkait diatur secara default dengan tepat.

Administrator basis data Anda perlu mengetahui dan memahami operasi pemeliharaan ini. Untuk SQL dokumentasi Postgre tentang autovacuum, lihat The Autovacuum Daemon.

Autovacuum bukan merupakan operasi "bebas sumber daya", tetapi operasi yang bekerja di latar belakang dan menghasilkan operasi pengguna sebanyak mungkin. Saat diaktifkan, autovacuum memeriksa tabel yang memiliki banyak tuple yang diperbarui atau dihapus. Autovacuum juga melindungi dari kehilangan data yang berumur sangat lama karena penyelesaian ID transaksi. Untuk informasi selengkapnya, lihat Mencegah kegagalan penyelesaian ID transaksi.

Autovacuum sebaiknya tidak dianggap sebagai operasi dengan overhead tinggi yang dapat dikurangi untuk mendapatkan performa yang lebih baik. Sebaliknya, tabel yang memiliki pembaruan dan penghapusan dengan kecepatan tinggi akan dengan cepat memburuk seiring waktu jika autovacuum tidak dijalankan.

Parameter autovacuum menentukan kapan dan seberapa keras autovacuum bekerja. Parameter autovacuum_vacuum_threshold dan autovacuum_vacuum_scale_factor menentukan kapan autovacuum dijalankan. Parameter autovacuum_max_workers, autovacuum_nap_time, autovacuum_cost_limit, dan autovacuum_cost_delay menentukan seberapa keras autovacuum bekerja. Untuk informasi selengkapnya tentang autovacuum, kapan dijalankan, dan parameter apa yang diperlukan, lihat Routine Vacuuming dalam dokumentasi Postgre. SQL

Kueri berikut ini menunjukkan jumlah tuple "mati" dalam tabel dengan nama table1:

SELECT relname, n_dead_tup, last_vacuum, last_autovacuum FROM 
pg_catalog.pg_stat_all_tables 
WHERE n_dead_tup > 0 and relname = 'table1';

Hasil kueri akan seperti berikut ini:

relname | n_dead_tup | last_vacuum | last_autovacuum
---------+------------+-------------+-----------------
 tasks   |   81430522 |             |
(1 row) 

Video praktik SQL terbaik Amazon RDS untuk Postgre

Tahun 2020 AWS Konferensi re:invent menyertakan presentasi tentang fitur baru dan praktik terbaik untuk bekerja dengan SQL Postgre di Amazon. RDS Video presentasi tersedia di sini:

Praktik terbaik untuk bekerja dengan SQL Server

Praktik terbaik untuk penerapan Multi-AZ dengan instans SQL Server DB meliputi hal berikut:

Saat bekerja dengan penyebaran SQL Server Multi-AZ, ingatlah bahwa Amazon RDS membuat replika untuk semua database SQL Server pada instans Anda. Jika Anda tidak ingin basis data tertentu memiliki replika sekunder, atur instans DB terpisah yang tidak menggunakan Multi-AZ untuk basis data tersebut.

Video praktik terbaik Amazon RDS untuk SQL Server

2019 AWS Konferensi re:invent menyertakan presentasi tentang fitur baru dan praktik terbaik untuk bekerja dengan Server SQL di Amazon. RDS Video presentasi tersedia di sini:

Menggunakan grup parameter DB

Sebaiknya Anda mencoba perubahan grup parameter DB pada instans DB pengujian sebelum menerapkan perubahan grup parameter pada instans DB produksi Anda. Pengaturan parameter mesin DB yang tidak tepat dalam grup parameter DB dapat memiliki efek merugikan yang tidak diinginkan, termasuk penurunan performa dan ketidakstabilan sistem. Selalu berhati-hati saat memodifikasi parameter mesin DB dan mencadangkan instans DB sebelum memodifikasi grup parameter DB.

Untuk informasi tentang mencadangkan instans DB, lihat Mencadangkan, memulihkan, dan mengekspor data.

Praktik terbaik untuk mengotomatiskan pembuatan instans DB

Ini adalah praktik RDS terbaik Amazon untuk membuat instans DB dengan versi minor yang disukai dari mesin database. Anda dapat menggunakan AWS CLI, Amazon RDSAPI, atau AWS CloudFormation untuk mengotomatiskan pembuatan instans DB. Bila Anda menggunakan metode ini, Anda hanya dapat menentukan versi utama dan Amazon RDS secara otomatis membuat instance dengan versi minor yang disukai. Misalnya, jika Postgre SQL 12.5 adalah versi minor yang disukai, dan jika Anda menentukan versi 12 dengancreate-db-instance, instans DB akan menjadi versi 12.5.

Untuk menentukan versi minor pilihan, Anda dapat menjalankan perintah describe-db-engine-versions dengan opsi --default-only seperti yang ditunjukkan dalam contoh berikut.

aws rds describe-db-engine-versions --default-only --engine postgres

{
    "DBEngineVersions": [
        {
            "Engine": "postgres",
            "EngineVersion": "12.5",
            "DBParameterGroupFamily": "postgres12",
            "DBEngineDescription": "PostgreSQL",
            "DBEngineVersionDescription": "PostgreSQL 12.5-R1",
            ...some output truncated...
        }
    ]
}

Untuk informasi tentang pembuatan instans DB secara pemrograman, lihat sumber daya berikut:

Video fitur RDS baru Amazon

2023 AWS Konferensi re:invent menyertakan presentasi tentang fitur Amazon baru. RDS Video presentasi tersedia di sini: