FAQ tentang PolarDB for PostgreSQL - PolarDB

Topik ini menjawab pertanyaan yang sering diajukan mengenai PolarDB for PostgreSQL.

Pertanyaan dasar

T: Apa itu PolarDB?
PolarDB adalah layanan database relasional cloud-native yang menyediakan kemampuan database online siap pakai dan telah diterapkan di lebih dari 10 wilayah. PolarDB kompatibel 100% dengan PostgreSQL. Secara default, sebuah kluster PolarDB menawarkan kapasitas penyimpanan hingga 500 TB.
Catatan
PolarStore (PSL4/PSL5) mendukung penyimpanan skala petabyte. Jika Anda memerlukan penyimpanan pada skala ini, hubungi kami untuk memesan sumber daya.
T: Mengapa cloud-native PolarDB memiliki performa lebih baik daripada database tradisional?
J: Dibandingkan dengan database tradisional, cloud-native PolarDB dapat menyimpan ratusan terabyte data serta menyediakan fitur-fitur seperti ketersediaan tinggi, keandalan tinggi, skalabilitas elastis cepat, dan backup tanpa kunci. Untuk informasi selengkapnya, lihat Manfaat.
T: Kapan PolarDB dirilis? Kapan tersedia untuk penggunaan komersial?
J: Layanan ini memasuki pratinjau publik pada September 2017 dan tersedia secara komersial pada Maret 2018.
T: Apa itu kluster dan node?
J: PolarDB Edisi Kluster menggunakan arsitektur kluster multi-node. Sebuah kluster mencakup satu node utama dan beberapa node read-only. Satu kluster PolarDB dapat diterapkan lintas zona tetapi tidak lintas wilayah. Kluster dikelola dan ditagih berdasarkan tingkat kluster. Untuk informasi selengkapnya, lihat Glosarium.
T: Bahasa pemrograman apa saja yang didukung?
J: PolarDB mendukung bahasa pemrograman seperti Java, Python, PHP, Go, C, C++, .NET, dan Node.js.
T: Setelah membeli PolarDB, apakah saya masih perlu membeli middleware database PolarDB-X untuk mengimplementasikan sharding?
J: Ya.
T: Apakah PolarDB mendukung partisi tabel?
J: Ya.
T: Apakah PolarDB secara otomatis menyertakan mekanisme partisi?
J: PolarDB melakukan partisi pada lapisan penyimpanan. Hal ini transparan bagi pengguna.

Penagihan

T: Apa saja yang termasuk dalam biaya PolarDB?
J: Biaya mencakup biaya untuk storage space, node komputasi, backup (yang mencakup kuota gratis), dan SQL Explorer (opsional). Untuk informasi selengkapnya, lihat Spesifikasi dan harga.
T: Apa yang termasuk dalam storage space yang ditagihkan?
J: Storage space yang ditagihkan mencakup file tabel database, file indeks, file undo log, file redo log, file slow log, dan sejumlah kecil file sistem. Untuk informasi selengkapnya, lihat Spesifikasi dan harga.

Akses kluster (pemisahan baca/tulis)

T: Bagaimana cara mengimplementasikan pemisahan baca/tulis di PolarDB?
J: Gunakan titik akhir kluster dalam aplikasi Anda untuk mengimplementasikan pemisahan baca/tulis berdasarkan mode baca/tulis yang dikonfigurasi. Untuk informasi selengkapnya, lihat Konfigurasikan proksi database.
T: Berapa banyak node read-only yang dapat didukung oleh kluster PolarDB?
J: PolarDB menggunakan arsitektur kluster terdistribusi. Sebuah kluster berisi satu node utama dan hingga 15 node read-only. Minimal satu node read-only diperlukan untuk memastikan ketersediaan tinggi.
T: Mengapa beban tidak seimbang di antara beberapa node read-only?
J: Beban dapat tidak seimbang di antara node read-only karena jumlah koneksi ke node read-only sedikit atau node read-only tidak termasuk saat titik akhir kluster kustom dikonfigurasi.
T: Apa penyebab beban tinggi atau rendah pada node utama?
J: Beban tinggi pada node utama dapat disebabkan oleh beberapa faktor: koneksi langsung ke titik akhir utama, node utama menerima permintaan baca, volume permintaan transaksi yang tinggi, latensi replikasi primary-secondary yang tinggi sehingga permintaan diarahkan ke node utama, atau pengecualian pada node read-only yang menyebabkan permintaan baca diarahkan ke node utama.
Beban rendah pada node utama mungkin menunjukkan bahwa database utama dikonfigurasi untuk menolak permintaan baca.
T: Bagaimana cara mengurangi beban pada node utama?
J: Gunakan metode berikut untuk mengurangi beban pada node utama:
- Gunakan titik akhir kluster untuk menghubungkan ke kluster PolarDB. Untuk informasi selengkapnya, lihat Konfigurasikan proksi database.
- Jika banyak transaksi menyebabkan tekanan tinggi pada node utama, Anda dapat mengaktifkan fitur pemisahan transaksi di Konsol. Fitur ini mengarahkan beberapa kueri dalam transaksi ke node read-only. Untuk informasi selengkapnya, lihat Opsi lanjutan—Pemisahan transaksi.
- Jika permintaan diarahkan ke node utama karena latensi replikasi, pertimbangkan untuk menurunkan tingkat konsistensi, misalnya menggunakan konsistensi akhir. Untuk informasi selengkapnya, lihat Opsi lanjutan—Tingkat konsistensi.
- Menerima permintaan baca pada node utama juga dapat menyebabkan beban tinggi. Anda dapat mengaktifkan fitur mengalihkan bacaan dari node utama di Konsol untuk mengurangi jumlah permintaan baca yang diarahkan ke node utama.
T: Mengapa saya tidak bisa membaca data yang baru saja dimasukkan?
J: Masalah ini mungkin disebabkan oleh konfigurasi tingkat konsistensi. Titik akhir kluster PolarDB mendukung tingkat konsistensi berikut:
- Konsistensi akhir: Tidak menjamin bahwa pembacaan dapat langsung melihat data yang baru dimasukkan, baik dalam sesi (koneksi) yang sama maupun berbeda.
- Konsistensi sesi: Menjamin bahwa Anda dapat membaca data yang dimasukkan dalam sesi yang sama.
Catatan
Tingkat konsistensi yang lebih tinggi menghasilkan performa yang lebih buruk dan tekanan lebih besar pada node utama. Pilih dengan hati-hati. Untuk sebagian besar skenario aplikasi, konsistensi sesi memastikan layanan berjalan dengan benar. Untuk beberapa pernyataan yang memerlukan konsistensi kuat, Anda dapat menggunakan Hint /* FORCE_MASTER */. Untuk informasi selengkapnya, lihat Tingkat konsistensi.
T: Bagaimana cara memaksa pernyataan SQL dieksekusi di node utama?
Saat menggunakan titik akhir kluster, tambahkan /* FORCE_MASTER */ atau /* FORCE_SLAVE */ sebelum pernyataan SQL untuk memaksa arah routing-nya. Untuk informasi selengkapnya, lihat Rute kustom—Hint.
- /* FORCE_MASTER */ memaksa permintaan diarahkan ke node utama. Ini dapat digunakan untuk beberapa permintaan baca yang memiliki persyaratan konsistensi tinggi.
- /* FORCE_SLAVE */ memaksa permintaan diarahkan ke node read-only. Ini dapat digunakan dalam beberapa skenario di mana proksi PolarDB memerlukan sintaks khusus untuk diarahkan ke node read-only guna memastikan kebenaran. Misalnya, pernyataan yang memanggil prosedur tersimpan atau menggunakan multistatement secara default diarahkan ke node utama.
Catatan
- Hint memiliki prioritas routing tertinggi dan tidak dibatasi oleh tingkat konsistensi atau pemisahan transaksi. Evaluasi sebelum digunakan.
- Jangan sertakan pernyataan yang mengubah variabel lingkungan dalam pernyataan Hint, seperti /*FORCE_SLAVE*/ set names utf8; . Jenis pernyataan ini dapat menyebabkan hasil kueri yang tidak terduga.
T: Dapatkah saya menetapkan titik akhir berbeda untuk layanan berbeda? Dapatkah titik akhir berbeda mencapai isolasi?
J: Anda dapat membuat beberapa titik akhir kustom untuk layanan berbeda. Jika node dasarnya berbeda, titik akhir kustom juga dapat memberikan isolasi dan tidak saling memengaruhi. Untuk informasi selengkapnya tentang cara membuat titik akhir kustom, lihat Konfigurasikan proksi database.
T: Jika terdapat beberapa node read-only, bagaimana cara membuat titik akhir node tunggal terpisah untuk salah satunya?
J: Buat titik akhir node tunggal hanya ketika mode baca/tulis titik akhir kluster adalah Read-only dan kluster memiliki tiga node atau lebih. Untuk langkah-langkah detail, lihat Konfigurasikan proksi database.
Peringatan
Setelah titik akhir node tunggal dibuat, jika node ini gagal, titik akhir tersebut mungkin tidak tersedia hingga 1 jam. Jangan gunakan di lingkungan produksi.
T: Berapa jumlah maksimum titik akhir node tunggal yang dapat dibuat dalam satu kluster?
J: Jika kluster Anda memiliki 3 node, Anda hanya dapat membuat titik akhir node tunggal untuk 1 dari node read-only. Jika kluster Anda memiliki 4 node, Anda dapat membuat titik akhir node tunggal untuk 2 dari node read-only. Logika yang sama berlaku untuk kluster dengan lebih banyak node.
T: Saya hanya menggunakan titik akhir utama, tetapi saya melihat bahwa node read-only juga memiliki beban. Apakah titik akhir utama juga mendukung pemisahan baca/tulis?
J: Titik akhir utama tidak mendukung pemisahan baca/tulis. Titik akhir ini selalu hanya terhubung ke node utama. Normal jika node read-only memiliki beban query per second (QPS) kecil, yang tidak terkait dengan titik akhir utama.

Manajemen dan pemeliharaan

T: Apakah terdapat latensi replikasi antara node utama dan node read-only?
A: Ya, terdapat penundaan dalam skala milidetik di antaranya.
T: Apa yang menyebabkan peningkatan latensi replikasi?
J: Latensi replikasi dapat meningkat dalam situasi berikut:
- Node utama memiliki beban tulis tinggi dan menghasilkan redo log lebih cepat daripada node read-only dapat menerapkannya.
- Node read-only memiliki beban yang terlalu tinggi, sehingga merebut sumber daya yang dibutuhkan untuk menerapkan redo log.
- Terjadi bottleneck I/O, yang menyebabkan pembacaan dan penulisan redo log menjadi lambat.
T: Bagaimana cara memastikan konsistensi kueri saat terdapat latensi replikasi?
J: Gunakan titik akhir kluster dan pilih tingkat konsistensi yang sesuai untuknya. Saat ini, tingkat konsistensi dari tertinggi ke terendah adalah konsistensi sesi, dan konsistensi akhir. Untuk informasi selengkapnya, lihat Konfigurasikan proksi database.
T: Dapatkah Recovery Point Objective (RPO) 0 dijamin jika terjadi kegagalan satu node?
J: Dengan parameter kluster database default, RPO bukan 0. Namun, Anda dapat mengatur RPO menjadi 0 dengan menyesuaikan parameter synchronous_commit. Untuk informasi selengkapnya tentang nilai parameter default, lihat Nilai parameter kluster default.
T: Bagaimana peningkatan spesifikasi (misalnya, dari 2 core dan 8 GB memori ke 4 core dan 16 GB memori) diimplementasikan di backend? Apa dampaknya terhadap layanan?
J: Baik proxy maupun node database PolarDB perlu ditingkatkan ke konfigurasi terbaru. Upgrade bergulir pada beberapa node digunakan untuk meminimalkan dampak terhadap layanan. Saat ini, setiap upgrade memakan waktu sekitar 10 hingga 15 menit. Dampak terhadap layanan berlangsung tidak lebih dari 30 detik. Selama periode ini, terjadi 1 hingga 3 putus sambungan sementara. Untuk informasi selengkapnya, lihat Ubah spesifikasi.
T: Berapa lama waktu yang dibutuhkan untuk menambahkan node? Apakah akan memengaruhi layanan?
J: Menambahkan node memakan waktu 5 menit dan tidak memengaruhi layanan. Untuk informasi selengkapnya tentang cara menambahkan node, lihat Tambahkan node read-only.
Catatan
Setelah node read-only baru ditambahkan, koneksi pemisahan baca/tulis baru akan meneruskan permintaan ke node read-only tersebut. Koneksi pemisahan baca/tulis yang dibuat sebelum penambahan node read-only baru tidak akan meneruskan permintaan ke node baru tersebut. Anda perlu memutus dan membuat ulang koneksi, misalnya dengan me-restart aplikasi.
T: Berapa lama waktu yang dibutuhkan untuk upgrade ke versi revisi terbaru? Apakah akan memengaruhi layanan?
J: PolarDB menggunakan upgrade bergulir multi-node untuk meminimalkan dampak terhadap layanan. Upgrade versi umumnya memakan waktu tidak lebih dari 30 menit. Selama upgrade, proksi database atau engine kernel DB akan di-restart, yang dapat menyebabkan putus sambungan sementara. Lakukan upgrade selama jam sepi dan pastikan aplikasi Anda memiliki mekanisme reconnect otomatis. Untuk informasi selengkapnya, lihat Manajemen versi minor.
T: Bagaimana cara kerja failover otomatis?
J: PolarDB menggunakan arsitektur kluster ketersediaan tinggi aktif-aktif. Sistem melakukan failover otomatis antara node utama baca/tulis dan node read-only. Sistem secara otomatis memilih node utama baru. Setiap node dalam kluster PolarDB memiliki prioritas failover, yang menentukan probabilitasnya dipilih sebagai node utama selama failover. Saat beberapa node memiliki prioritas yang sama, mereka memiliki probabilitas yang sama untuk dipilih sebagai node utama. Untuk informasi selengkapnya, lihat Failover otomatis dan manual primary/secondary.
T: Apa arsitektur proksi database? Apakah memiliki mekanisme failover? Bagaimana ketersediaan tingginya dijamin?
J: Proksi database menggunakan arsitektur ketersediaan tinggi dual-node dan mendistribusikan traffic secara merata di antara dua node proksi. Sistem terus memantau kesehatan node proksi. Jika suatu node gagal, sistem secara proaktif memutus koneksi-nya, dan node sehat yang tersisa secara otomatis mengambil alih seluruh traffic untuk memastikan layanan tidak terganggu. Secara bersamaan, sistem secara otomatis membangun kembali dan memulihkan node proksi yang gagal. Proses ini biasanya selesai dalam waktu sekitar 2 menit, di mana kluster database tetap dapat diakses.
Dalam kasus jarang terjadi, koneksi ke node yang gagal mungkin tidak segera diputus dan menjadi tidak responsif. Untuk menangani hal ini, konfigurasikan kebijakan timeout pada client, seperti parameter JDBC socketTimeout dan connectTimeout. Hal ini memungkinkan lapisan aplikasi untuk segera mendeteksi dan menghentikan koneksi yang tertunda, meningkatkan toleransi kesalahan dan efisiensi respons sistem.

Backup dan pemulihan

T: Metode backup apa yang digunakan oleh PolarDB?
J: PolarDB menggunakan snapshot untuk backup. Untuk informasi selengkapnya, lihat Metode backup 2: Backup manual.
T: Seberapa cepat pemulihan database?
J: Saat ini, pemulihan (kloning) dari set cadangan (snapshot) memakan waktu 40 menit per TB. Jika Anda memulihkan ke titik waktu tertentu, waktu untuk menerapkan redo log juga harus diperhitungkan. Bagian pemulihan ini memakan waktu sekitar 20 hingga 70 detik per GB. Waktu pemulihan total adalah jumlah dari kedua bagian tersebut.

Performa dan kapasitas

T: Berapa jumlah maksimum tabel? Pada jumlah berapa performa mulai menurun?
J: Jumlah maksimum tabel dibatasi oleh jumlah file. Untuk informasi selengkapnya, lihat Batasan.
T: Dapatkah partisi tabel meningkatkan performa kueri PolarDB?
J: Ya. Jika kueri dapat dibatasi ke partisi tertentu, performa dapat ditingkatkan.
T: Apakah PolarDB mendukung pembuatan 10.000 database? Berapa jumlah maksimum database?
J: PolarDB mendukung pembuatan 10.000 database. Jumlah maksimum database dibatasi oleh jumlah file. Untuk informasi selengkapnya, lihat Batasan.
T: Bagaimana IOPS dibatasi dan diisolasi? Apakah beberapa node kluster PolarDB bersaing untuk I/O?
J: IOPS untuk setiap node dalam kluster PolarDB diatur sesuai spesifikasinya. IOPS setiap node diisolasi secara independen dan tidak memengaruhi node lain.
T: Apakah performa node utama akan terpengaruh jika performa node read-only melambat?
J: Beban yang terlalu tinggi atau peningkatan latensi replikasi pada node read-only mungkin sedikit meningkatkan konsumsi memori node utama.
T: Apa dampak performa dari mengaktifkan SQL Explorer (audit log SQL lengkap)?
J: Tidak ada dampak.
T: Protokol jaringan berkecepatan tinggi apa yang digunakan oleh PolarDB?
J: PolarDB menggunakan teknologi Remote Direct Memory Access (RDMA) ganda 25 Gbps antara node komputasi database dan node penyimpanan, serta antara replika data penyimpanan. Hal ini memberikan performa I/O kuat dengan latensi rendah dan throughput tinggi.
T: Berapa bandwidth maksimum untuk koneksi eksternal ke PolarDB?
J: Bandwidth maksimum untuk koneksi eksternal ke PolarDB adalah 10 Gbit/s.
T: Apa yang harus saya lakukan jika proses memulai ulang sebuah node memakan waktu lama?
J: Semakin banyak file dalam kluster Anda, semakin lama waktu yang dibutuhkan untuk restart node. Dalam kasus ini, Anda dapat mempercepat restart dengan mengatur parameter innodb_fast_startup ke ON. Untuk informasi selengkapnya tentang cara memodifikasi parameter, lihat Atur parameter kluster dan node.