Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Halaman ini menjelaskan beberapa konfigurasi yang dikontrol pengguna dan dapat menyebabkan pemadaman layanan instance Spanner dikecualikan dari Perjanjian Tingkat Layanan (SLA) Spanner, yang mengecualikan pemadaman layanan "yang disebabkan oleh faktor di luar kendali wajar Google". Dokumen ini juga memberikan
panduan tentang cara menghindari konfigurasi ini.
Spanner mengelola banyak aspek operasi database, seperti
pemisahan dan penyeimbangan ulang data, replikasi, failover, serta semua update hardware dan
software. Anda dapat mengonfigurasi banyak perilaku ini dengan setelan bawaan dan API administratif. Workload Anda juga bergantung pada komponen lain selain Spanner, seperti aplikasi dan jaringan Anda.
Konfigurasi yang dikontrol pelanggan ini dapat meningkatkan risiko periode nonaktif instance, bergantung pada beban database dan parameter konfigurasi lainnya.
Jika instance Anda menjadi tidak responsif, dan jika Google menentukan bahwa instance tersebut tidak mematuhi batas operasional yang dijelaskan di halaman ini, maka periode nonaktif yang terjadi mungkin tidak dicakup oleh (atau tidak diperhitungkan dalam) SLA Spanner.
Konfigurasi yang dikecualikan dari SLA Spanner
Konfigurasi berikut dikecualikan dari SLA Spanner:
Jika instance Anda dikonfigurasi dan digunakan sedemikian rupa sehingga menyebabkan workload
membebani instance, maka instance tersebut tidak tercakup dalam SLA.
Waktu nonaktif instance yang disebabkan oleh tindakan atau kelalaian Anda yang disengaja tidak tercakup dalam SLA
Jika Anda menonaktifkan Spanner API
atau API Google Cloud lain yang diperlukan untuk membuat dan terhubung ke
Spanner, maka hal tersebut tidak tercakup dalam SLA.
Tidak tersedianya Spanner API yang disebabkan oleh konfigurasi jaringan Anda, seperti aturan proxy dan firewall, tidak tercakup dalam SLA.
Ketidaktersediaan aplikasi karena klien yang tidak update atau salah konfigurasi tidak tercakup dalam SLA. Khususnya, pastikan Anda menggunakan versi klien terbaru dengan dependensi yang didukung. Misalnya, aplikasi Java harus menggunakan BOM Google
(bill of materials) dengan pengelola paket, seperti Gradle atau Maven.
Sebaiknya siapkan pemberitahuan dan pemantauan menggunakan
Cloud Monitoring.
Konfigurasi yang harus dihindari
Untuk mempertahankan cakupan SLA Spanner, Anda harus menghindari konfigurasi berikut:
CPU kelebihan beban: Jika pemakaian CPU Anda terus-menerus tinggi, ukuran
instance Anda tidak sesuai untuk workload Anda, dan instance mungkin tidak
tercakup oleh SLA. Rekomendasi pemakaian CPU Spanner
memberikan overhead untuk peristiwa failover, di mana resource komputasi yang tersisa
membantu mengakomodasi traffic dari bagian instance yang tidak tersedia. Anda dapat
menggunakan metrik penggunaan CPU Spanner
untuk memantau penggunaan CPU.
Penyimpanan penuh: Spanner hanya menagih Anda untuk penyimpanan yang Anda gunakan. Namun, setiap node, atau unit komputasi, memiliki batas
untuk jumlah penyimpanan yang dapat dikelolanya. Jika ukuran instance Anda tidak sesuai
untuk penyimpanan yang dapat dialamatkan per node, instance mungkin tidak tercakup
dalam SLA. Anda dapat menggunakan
metrik penggunaan penyimpanan Spanner untuk memantau
penggunaan penyimpanan.
Batas kuota: Resource node dibatasi oleh kuota per pengguna.
Jika Anda tidak meminta peningkatan kuota terlebih dahulu, hal ini dapat menyebabkan kelebihan beban pada resource komputasi, yang mungkin tidak tercakup dalam SLA. Permintaan penambahan kuota yang
memerlukan persetujuan dari Google biasanya dipenuhi dalam waktu satu hari.
Sesi yang kurang disediakan: Klien Spanner menggunakan
channel gRPC
untuk berkomunikasi dengan endpoint Google Cloud untuk kueri dan administrasi. Jika
lingkungan klien Anda tidak menyediakan saluran yang cukup untuk mendukung volume
permintaan workload, aplikasi Anda mungkin mengalami latensi tinggi dan throughput
permintaan rendah yang mungkin tidak tercakup dalam SLA.
Kelebihan beban koneksi: Banyak Spanner API dapat dicoba lagi dengan aman jika terjadi kegagalan sementara, seperti kebuntuan transaksi dalam kueri, masalah jaringan, atau batas kecepatan untuk API administratif. Upaya
coba lagi yang terlalu agresif dapat membebani koneksi yang ada, sehingga menyebabkan
kehabisan resource atau throttling tambahan. Peningkatan latensi atau penurunan throughput mungkin tidak tercakup dalam SLA. Untuk mengetahui informasi selengkapnya, lihat
mengelola waktu tunggu dan percobaan ulang klien.
Overload hard disk drive (HDD):Penyimpanan bertingkat
memungkinkan Anda menyimpan data Spanner di campuran solid-state drive
(SSD) dan hard disk drive (HDD). Jika beban disk Anda pada penyimpanan HDD mencapai
100%, instance Spanner Anda akan mengalami peningkatan latensi yang signifikan dan mungkin tidak tercakup oleh SLA. Anda dapat menggunakan
metrik penyimpanan bertingkat Spanner
untuk memantau beban disk.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-17 UTC."],[],[],null,["# Spanner operational guidelines\n\nThis page describes some of the user-controlled configurations that can cause an\noutage for a Spanner instance to be excluded from the\nSpanner Service Level Agreement (SLA), which excludes outages\n\"caused by factors outside of Google's reasonable control\". It also provides\nguidelines on how to avoid these configurations.\n\nSpanner manages many aspects of database operations, such as\nsplitting and rebalancing data, replication, failover, and all hardware and\nsoftware updates. You can configure many of these behaviors with built-in\nsettings and administrative APIs. Your workloads also depend on other components\nin addition to Spanner, such as your applications and network.\nThese customer-controlled configurations may increase the risk of instance\ndowntime, depending on your database load and other configuration parameters.\n\nIf your instance becomes unhealthy, and if Google determines that the instance\nis out of compliance with the operational limits described on this page, then\nany resulting downtime may not be covered by (or does not count against) the\nSpanner SLA.\n| **Note:** You're responsible for monitoring your Spanner instances and verifying that they are correctly sized and configured for the type of workloads that you're running.\n\nConfigurations excluded from the Spanner SLA\n--------------------------------------------\n\nThe following configurations are excluded from the Spanner SLA:\n\n- If your instance is configured and used in a way that causes the workload to overload the instance, then it isn't covered by the SLA.\n- Downtime of instances that results from your voluntary actions or inactions isn't covered by the SLA\n- If you disable the [Spanner API](/spanner/docs/getting-started/set-up#set_up_a_project) or other Google Cloud APIs that are required to create and connect to Spanner, then it isn't covered by the SLA.\n- Unavailability of the Spanner API that is the result of your network configuration, such as proxy and firewall rules, isn't covered by the SLA.\n- Application unavailability due to out-of-date or misconfigured [clients](/spanner/docs/reference/libraries) isn't covered by the SLA. In particular, verify that you are using recent client versions with supported dependencies. For example, Java applications should use [Google's BOM](/java/docs/bom) (bill of materials) with a package manager, such as Gradle or Maven.\n\nWe recommend that you set up alerts and monitoring using\n[Cloud Monitoring](/spanner/docs/monitoring-cloud).\n\n### Configurations to avoid\n\nTo maintain Spanner SLA coverage, you must avoid the following\nconfigurations:\n\n- **CPU overload** : If your CPU utilization is consistently high, then your instance isn't properly sized for your workload, and the instance might not be covered by the SLA. Spanner [CPU utilization recommendations](/spanner/docs/compute-capacity#change-compute-capacity) provide overhead for a failover event, where the remaining compute resources help to accommodate traffic from unavailable parts of the instance. You can use Spanner [CPU utilization metrics](/spanner/docs/cpu-utilization) to monitor CPU utilization.\n- **Full storage** : Spanner bills you only for the storage that you use. However, each node, or unit of compute, has a [limit](/spanner/quotas#database-limits) for the amount of storage it can manage. If your instance isn't properly sized for the addressable storage per node, then the instance might not be covered by the SLA. You can use Spanner [storage utilization metrics](/spanner/docs/storage-utilization) to monitor storage utilization.\n- **Quota limit:** Node resources are limited by per-user [quotas](/spanner/quotas). Failure to request quota increases in advance might result in compute resource overload, which might not be covered by the SLA. Quota increase requests that require approval from Google are typically fulfilled within one day.\n- **Under provisioned sessions** : Spanner clients use [gRPC channels](/spanner/docs/sessions#configure_the_number_of_sessions_and_grpc_channels_in_the_pools) to communicate with Google Cloud endpoints for queries and administration. If your client environments don't provide enough channels to support the request volume of a workload, your applications might experience high latency and low request throughput that might not be covered by the SLA.\n- **Connection overload:** Many Spanner APIs can be safely retried in the event of a transient failure, such as a transaction deadlock in a query, a network issue, or rate limits for administrative APIs. Overly aggressive retries might overwhelm existing connections, causing resource exhaustion or additional throttling. The increased latency or reduced throughput might not be covered by the SLA. For more information, see [managing client timeouts and retries](/spanner/docs/custom-timeout-and-retry).\n- **Hard disk drive (HDD) overload:** [Tiered storage](/spanner/docs/tiered-storage) lets you store your Spanner data on a mix of solid-state drives (SSD) and hard disk drives (HDD). If your disk load on HDD storage reaches 100%, your Spanner instance experiences significantly increased latency and might not be covered by the SLA. You can use Spanner [tiered storage metrics](/spanner/docs/monitoring-console#tiered_storage_charts_and_metrics) to monitor disk load.\n\nWhat's next\n-----------\n\n- Learn [best practices for improving Spanner performance and availability using the launch checklist](/spanner/docs/launch-checklist)."]]
