FAQ untuk PolarDB - PolarDB

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

Pertanyaan dasar

T: Apa itu PolarDB?
PolarDB adalah layanan database relasional berbasis cloud yang menyediakan database siap pakai. Layanan ini diterapkan di pusat data di lebih dari 10 wilayah. PolarDB sepenuhnya kompatibel dengan PostgreSQL. Secara default, sebuah kluster PolarDB menyediakan 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 PolarDB cloud-native lebih unggul dibandingkan database tradisional?
J: Dibandingkan dengan database tradisional, PolarDB cloud-native 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: PolarDB dirilis dalam 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 memiliki 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, Anda perlu.
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 ruang penyimpanan, node komputasi, backup (yang mencakup kuota gratis), dan SQL Explorer (opsional). Untuk informasi selengkapnya, lihat Spesifikasi dan harga.
T: Apa yang termasuk dalam ruang penyimpanan yang dikenai biaya?
J: Ruang penyimpanan yang dikenai biaya mencakup file tabel database, file indeks, file log undo, file log redo, file log lambat, dan sejumlah kecil file sistem. Untuk informasi selengkapnya, lihat Spesifikasi dan harga.
T: Bagaimana cara menggunakan paket penyimpanan PolarDB?
J: Kluster berlangganan dan bayar sesuai pemakaian dapat menggunakan paket penyimpanan untuk mengimbangi biaya penyimpanan. Misalnya, jika Anda memiliki tiga kluster, masing-masing dengan penyimpanan 40 GB (total 120 GB), ketiga kluster tersebut dapat berbagi paket penyimpanan 100 GB. Tambahan 20 GB akan ditagih berdasarkan sistem bayar sesuai pemakaian. Untuk informasi selengkapnya, lihat Membeli paket penyimpanan.

Akses kluster (pemisahan baca/tulis)

T: Bagaimana cara mengimplementasikan pemisahan baca/tulis di PolarDB?
J: Anda dapat mengimplementasikan pemisahan baca/tulis menggunakan titik akhir kluster di aplikasi Anda. Pemisahan ini berdasarkan mode baca/tulis yang dikonfigurasi. Untuk informasi selengkapnya, lihat Mengonfigurasi 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. Diperlukan minimal satu node read-only 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 primer/sekunder yang tinggi sehingga menyebabkan permintaan dialihkan ke node utama, atau pengecualian pada node read-only yang menyebabkan permintaan baca dialihkan ke node utama.
Beban rendah pada node utama dapat terjadi karena opsi untuk mengalihkan bacaan dari node utama diaktifkan.
T: Bagaimana cara mengurangi beban pada node utama?
J: Anda dapat menggunakan metode berikut untuk mengurangi beban pada node utama:
- Gunakan titik akhir kluster untuk terhubung ke kluster PolarDB. Untuk informasi selengkapnya, lihat Mengonfigurasi 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 dialihkan 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 dialihkan ke node utama.
T: Mengapa saya tidak dapat 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 sesi yang berbeda.
- Konsistensi sesi: Menjamin bahwa Anda dapat membaca data yang dimasukkan dalam sesi yang sama.
Catatan
Tingkat konsistensi yang lebih tinggi menghasilkan kinerja yang lebih buruk dan tekanan yang 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 peruteannya. Untuk informasi selengkapnya, lihat Rute kustom - Hint.
- /* FORCE_MASTER */ memaksa permintaan dialihkan ke node utama. Ini dapat digunakan untuk beberapa permintaan baca yang memiliki persyaratan konsistensi tinggi.
- /* FORCE_SLAVE */ memaksa permintaan dialihkan ke node read-only. Ini dapat digunakan dalam beberapa skenario di mana proksi PolarDB memerlukan sintaks khusus untuk dialihkan ke node read-only guna memastikan kebenaran. Misalnya, pernyataan yang memanggil prosedur tersimpan atau menggunakan multistatement secara default dialihkan ke node utama.
Catatan
- Hint memiliki prioritas perutean 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 yang berbeda untuk layanan yang berbeda? Dapatkah titik akhir yang berbeda mencapai isolasi?
J: Ya. Anda dapat membuat beberapa titik akhir kustom untuk layanan yang 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 Mengonfigurasi proksi database.
T: Jika terdapat beberapa node read-only, bagaimana cara membuat titik akhir node tunggal yang terpisah untuk salah satunya?
J: Anda dapat membuat 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 Mengonfigurasi proksi database.
Peringatan
Setelah titik akhir node tunggal dibuat, jika node ini gagal, titik akhir mungkin tidak tersedia hingga 1 jam. Jangan menggunakannya 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 QPS (query per second) kecil, yang tidak terkait dengan titik akhir utama.

Manajemen dan pemeliharaan

T: Apakah ada latensi replikasi antara node utama dan node read-only?
J: Ya, terdapat latensi tingkat milidetik di antara keduanya.
T: Apa penyebab peningkatan latensi replikasi?
J: Latensi replikasi dapat meningkat dalam situasi berikut:
- Node utama memiliki beban tulis tinggi dan menghasilkan log redo lebih cepat daripada node read-only dapat menerapkannya.
- Node read-only memiliki beban yang terlalu tinggi, sehingga mengambil alih sumber daya yang diperlukan untuk menerapkan log redo.
- Terjadi bottleneck I/O, yang menyebabkan pembacaan dan penulisan log redo menjadi lambat.
T: Bagaimana cara memastikan konsistensi kueri saat terjadi latensi replikasi?
J: Anda dapat menggunakan titik akhir kluster dan memilih tingkat konsistensi yang sesuai untuknya. Saat ini, tingkat konsistensi dari tertinggi ke terendah adalah konsistensi sesi, dan konsistensi akhir. Untuk informasi selengkapnya, lihat Mengonfigurasi proksi database.
T: Dapatkah RPO 0 dijamin jika terjadi kegagalan satu node?
J: Dengan parameter kluster database default, Recovery Point Objective (RPO) bukan 0. Namun, Anda dapat mengatur RPO menjadi 0 dengan menyesuaikan parameter synchronous_commit. Untuk informasi selengkapnya, lihat Nilai parameter kluster default.
T: Bagaimana spesifikasi peningkatan (misalnya, dari 2 core dan memori 8 GB menjadi 4 core dan memori 16 GB) diimplementasikan di backend? Apa dampaknya terhadap layanan?
J: Baik proxy maupun node database PolarDB perlu ditingkatkan ke konfigurasi terbaru. Peningkatan bergulir pada beberapa node digunakan untuk meminimalkan dampak terhadap layanan. Saat ini, setiap peningkatan memakan waktu sekitar 10 hingga 15 menit. Dampak terhadap layanan berlangsung tidak lebih dari 30 detik. Selama periode ini, terjadi 1 hingga 3 kesalahan koneksi sementara. Untuk informasi selengkapnya, lihat Mengubah spesifikasi.
T: Berapa lama waktu yang dibutuhkan untuk menambahkan node? Apakah akan memengaruhi layanan?
J: Menambahkan node memakan waktu 5 menit dan tidak berdampak pada layanan. Untuk informasi selengkapnya tentang cara menambahkan node, lihat Menambahkan 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 meningkatkan ke versi revisi terbaru? Apakah akan memengaruhi layanan?
J: PolarDB menggunakan peningkatan bergulir multi-node untuk meminimalkan dampak terhadap layanan. Peningkatan versi umumnya memakan waktu tidak lebih dari 30 menit. Selama peningkatan, proksi database atau mesin kernel DB akan direstart, yang dapat menyebabkan kesalahan koneksi sementara. Lakukan peningkatan selama jam non-sibuk dan pastikan aplikasi Anda memiliki mekanisme koneksi ulang 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. Ketika beberapa node memiliki prioritas yang sama, mereka memiliki probabilitas yang sama untuk dipilih sebagai node utama. Untuk informasi selengkapnya, lihat Failover primer/sekunder otomatis dan manual.
T: Apa arsitektur proksi database? Apakah memiliki mekanisme failover? Bagaimana ketersediaan tingginya dijamin?
J: Proksi database menggunakan arsitektur ketersediaan tinggi dua node. Trafik didistribusikan secara merata antara dua node proksi. Sistem terus-menerus memeriksa kesehatan node proksi. Jika terdeteksi kegagalan node, koneksi ke node tersebut diputus, dan node sehat yang tersisa secara otomatis mengambil alih seluruh trafik untuk memastikan kelangsungan layanan. Sistem kemudian secara otomatis membangun kembali dan memulihkan node proksi yang rusak. Proses ini biasanya memakan waktu sekitar dua menit. Selama periode ini, kluster database tetap dapat diakses.
Dalam kasus langka, koneksi ke node yang rusak mungkin tidak diputus tepat waktu dan tidak dapat lagi merespons permintaan. Untuk menangani situasi seperti ini, kami merekomendasikan agar Anda mengonfigurasi kebijakan timeout yang wajar di klien, seperti socketTimeout dan connectTimeout untuk JDBC. Hal ini memungkinkan lapisan aplikasi untuk segera mendeteksi dan menghentikan koneksi yang tertunda, sehingga 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 terabyte (TB). Jika Anda memulihkan ke titik waktu tertentu, waktu untuk menerapkan log redo juga harus diperhitungkan. Bagian pemulihan ini memakan waktu sekitar 20 hingga 70 detik per gigabyte (GB). Waktu pemulihan total adalah jumlah dari kedua bagian ini.

Kinerja dan kapasitas

T: Berapa jumlah maksimum tabel? Pada jumlah berapa kinerja mulai menurun?
J: Jumlah maksimum tabel dibatasi oleh jumlah file. Untuk informasi selengkapnya, lihat Batasan.
T: Apakah partisi tabel dapat meningkatkan kinerja kueri PolarDB?
J: Ya. Jika kueri dapat dibatasi pada partisi tertentu, kinerja 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 dengan spesifikasinya. IOPS setiap node diisolasi secara independen dan tidak memengaruhi node lain.
T: Apakah kinerja node utama akan terpengaruh jika kinerja node read-only melambat?
J: Beban yang terlalu tinggi atau peningkatan latensi replikasi pada node read-only dapat sedikit meningkatkan konsumsi memori node utama.
T: Apa dampak kinerja dari mengaktifkan SQL Explorer (audit log SQL lengkap)?
J: Tidak ada dampak terhadap kinerja.
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 kinerja I/O yang 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 restart node memakan waktu lama?
J: Semakin banyak file di kluster Anda, semakin lama waktu yang dibutuhkan untuk me-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 Mengatur parameter kluster dan node.