Kesalahan umum dan pemecahan masalah untuk jadwal cadangan - Data Management

Kesalahan dapat terjadi saat mengonfigurasi jadwal cadangan, pra-pemeriksaan jadwal cadangan atau tugas pemulihan, atau menjalankan tugas pemulihan di Pemulihan Bencana Data. Topik ini menjelaskan kesalahan umum beserta solusi untuk memperbaiki kesalahan tersebut.

Catatan

Jika kesalahan yang Anda temui tidak dijelaskan dalam topik ini, atau masalah tetap ada setelah menggunakan solusi yang disediakan, hubungi dukungan teknis di Grup DingTalk (ID: 35585947).

Daftar kesalahan umum berdasarkan jenis

Kesalahan Umum Saat Mengonfigurasi Jadwal Cadangan

Gagal Menguji Koneksi ke Database Sumber

Kesalahan Umum Saat Pra-Pemeriksaan Jadwal Cadangan atau Tugas Pemulihan

Gagal Memeriksa Koneksi ke Database Sumber
Gagal Memeriksa Izin pada Database Sumber
Gagal Memeriksa Koneksi ke OSS
Gagal Memeriksa Apakah Fitur Pencatatan Biner Diaktifkan untuk Database Sumber
Gagal Memeriksa Format Log Biner dari Database Sumber
Gagal Memeriksa Apakah Parameter binlog_row_image dari Database Sumber Diatur ke FULL
Gagal Memeriksa ID Server dari Database Sumber
Gagal Memeriksa Keberadaan File Log Biner di Database Sumber
Gagal Memeriksa Mesin Penyimpanan
Gagal Memeriksa Format Kata Sandi Database MySQL
Konflik Nama Objek

Kode Kesalahan Umum untuk Fitur Unduhan Lanjutan

DBS-DownloadTask.Region
DBS-DownloadTask.InstanceInfo
DBS-DownloadTask.DbType
DBS-DownloadTask.CustinId
DBS-DownloadTask.CustinName
DBS-DownloadTask.user
DBS-DownloadTask.Instance.Version
DBS-DownloadTask.Instance.Storage.Type
DBS-DownloadTask.Instance.Param
DBS-DownloadTask

Kode Kesalahan Umum Saat Menjalankan Tugas

Kesalahan umum yang mungkin terjadi saat Anda mengonfigurasi jadwal cadangan

Gagal menguji koneksi ke database sumber

Skenario: Pengujian koneksi gagal saat mengonfigurasi jadwal cadangan.

Penyebab:

Nama akun database atau kata sandi tidak valid.
Database menolak akses dari alamat IP Pemulihan Bencana Data.
Firewall dikonfigurasikan untuk server atau jaringan tempat database berada.
Komunikasi jaringan tidak normal.

Solusi:

Klik Check di konsol Pemulihan Bencana Data untuk melihat detail kegagalan pengujian koneksi.
Lakukan pemeriksaan berikut untuk memecahkan masalah:
- Periksa apakah nama akun database atau kata sandi tidak valid, atau apakah database menolak akses dari alamat IP Pemulihan Bencana Data.
  1. Periksa apakah nama akun database dan kata sandi valid.
    Temukan server yang dapat terhubung ke database sumber. Di server tersebut, gunakan nama akun database dan kata sandi yang ditentukan saat mengonfigurasi jadwal cadangan untuk terhubung ke database. Dengan cara ini, Anda dapat memeriksa apakah nama akun database dan kata sandi valid. Jika tidak valid, tentukan nama akun database dan kata sandi yang benar lalu uji koneksi lagi.
  2. Jika nama akun database dan kata sandi valid, periksa apakah database memblokir alamat IP Pemulihan Bencana Data.
    - Jika database adalah database MySQL, gunakan klien MySQL untuk terhubung ke database dan jalankan pernyataan SQL berikut untuk mendapatkan alamat IP akun database yang ditentukan. Kemudian, periksa apakah akses jarak jauh ke database diizinkan dari alamat IP tersebut.
```
SELECT host,user,authentication_string,password_expired,account_locked FROM mysql.user WHERE user='[$Username]';
```
      Catatan
      Ganti [$Username] dengan akun database yang ditentukan saat mengonfigurasi jadwal cadangan.
    - Jika database adalah database SQL Server,
      - Jika gateway cadangan diinstal di server database sumber, atur parameter Address ke localhost.
      - Periksa apakah firewall dikonfigurasikan untuk server tempat database berada. Selain itu, periksa apakah titik akhir atau pemicu di database sumber menolak akses dari alamat IP Pemulihan Bencana Data.
    - Jika database adalah database Oracle, periksa apakah parameter TCP.VALIDNODE_CHECKING di file sqlnet.ora diatur ke YES. Jika parameter diatur ke YES, database menolak akses dari alamat IP Pemulihan Bencana Data.
- Periksa apakah firewall dikonfigurasikan untuk server tempat database berada dan kebijakan firewall dikonfigurasikan untuk menolak akses ke server, atau apakah komunikasi jaringan tidak normal.
  1. Periksa apakah firewall dikonfigurasikan untuk server tempat database berada dan kebijakan firewall dikonfigurasikan untuk menolak akses ke server.
    - Jika database diterapkan di server Windows, temukan Windows Defender Firewall dari Control Panel dan periksa apakah kebijakan firewall dikonfigurasikan untuk menolak akses ke server.
    - Jika database diterapkan di server Linux, jalankan perintah iptables -L dan periksa apakah kebijakan firewall dikonfigurasikan untuk menolak akses ke server.
    - Jika database sumber diterapkan di Instance ECS (Elastic Compute Service), periksa apakah blok CIDR server Pemulihan Bencana Data ditambahkan ke aturan grup keamanan instance ECS. Untuk informasi lebih lanjut, lihat Tambahkan Aturan Grup Keamanan. Anda bisa mendapatkan blok CIDR server Pemulihan Bencana Data di konsol Pemulihan Bencana Data.
  2. Periksa apakah akses dari blok CIDR server Pemulihan Bencana Data diizinkan di firewall jaringan database. Dalam contoh ini, Cloud Firewall digunakan.
    1. Masuk ke Konsol Cloud Firewall. Di panel navigasi kiri, pilih Access Control.
    2. Di halaman Batas Internet, periksa apakah kebijakan dikonfigurasikan untuk Cloud Firewall untuk menolak akses dari blok CIDR server Pemulihan Bencana Data. Anda bisa mendapatkan blok CIDR server Pemulihan Bencana Data di konsol Pemulihan Bencana Data.
    Catatan
    Jika kesalahan bukan disebabkan oleh firewall tetapi tes koneksi Telnet masih gagal, komunikasi jaringan Pemulihan Bencana Data mungkin tidak normal. Hubungi dukungan teknis di Grup DingTalk.

Kesalahan umum yang mungkin terjadi saat Anda pra-pemeriksaan jadwal cadangan atau tugas pemulihan

Gagal memeriksa koneksi ke database sumber

Skenario: Pra-pemeriksaan gagal untuk jadwal cadangan atau tugas pemulihan saat memulai jadwal cadangan atau tugas pemulihan.

Penyebab:

Nama akun database atau kata sandi tidak valid.
Database menolak akses dari alamat IP Pemulihan Bencana Data.
Firewall dikonfigurasikan untuk server atau jaringan tempat database berada.
Komunikasi jaringan tidak normal.

Solusi: Untuk informasi lebih lanjut, lihat bagian Gagal Menguji Koneksi ke Database Sumber dari topik ini.

Gagal memeriksa izin pada database sumber

Skenario: Pra-pemeriksaan gagal untuk jadwal cadangan atau tugas pemulihan saat memulai jadwal cadangan atau tugas pemulihan.

Penyebab:

Akun database yang ditentukan untuk jadwal cadangan tidak memiliki izin untuk mengakses database.
Akun database yang ditentukan untuk tugas pemulihan tidak memiliki izin untuk menulis data ke database atau memperbarui tabel di database.

Solusi: Periksa izin akun database yang digunakan. Jika akun database tidak memiliki izin yang cukup, kami sarankan memberikan izin yang diperlukan kepada akun tersebut atau menggunakan akun database lain dengan izin yang sesuai.

Catatan

Jadwal Cadangan: Untuk informasi lebih lanjut tentang cara mengubah akun database untuk jadwal cadangan, lihat Bagaimana Cara Memodifikasi Sumber Cadangan?
Tugas Pemulihan: Kami sarankan mengonfigurasi tugas pemulihan lainnya. Anda dapat menghapus tugas pemulihan yang telah lulus pra-pemeriksaan.

Gagal memeriksa koneksi ke OSS

Skenario: Pra-pemeriksaan gagal untuk jadwal cadangan atau tugas pemulihan saat memulai jadwal cadangan atau tugas pemulihan.

Penyebab:

Saat mengonfigurasi jadwal cadangan, parameter Jenis Penyimpanan Cadangan diatur ke OSS For User dan Bucket Object Storage Service (OSS) milik pengguna ditentukan sebagai penyimpanan cadangan. Namun, Pemulihan Bencana Data tidak berwenang untuk mengakses OSS.
Kesalahan internal terjadi.

Solusi:

Di halaman Configure Task dari jadwal cadangan, periksa apakah penyimpanan bawaan atau Bucket OSS milik pengguna digunakan sebagai penyimpanan cadangan untuk jadwal cadangan. Jika Bucket OSS milik pengguna digunakan, masuk ke konsol OSS dan periksa apakah bucket yang ditampilkan di konsol Pemulihan Bencana Data ada dan apakah Pemulihan Bencana Data berwenang untuk mengakses bucket tersebut. Untuk informasi lebih lanjut, lihat Bagaimana Cara Mengaktifkan DBS?
Jika Bucket OSS ada dan Pemulihan Bencana Data berwenang untuk mengakses OSS, kesalahan layanan internal mungkin terjadi. Hubungi dukungan teknis di Grup DingTalk.

Gagal memeriksa apakah fitur pencatatan biner diaktifkan untuk database sumber

Skenario: Pemulihan Bencana Data gagal memeriksa apakah fitur pencatatan biner diaktifkan untuk database sumber.

Solusi: Item pemeriksaan ini digunakan untuk memeriksa apakah fitur pencatatan biner diaktifkan untuk database sumber. Jika pemeriksaan gagal, fitur pencatatan biner dinonaktifkan untuk database sumber. Untuk menyelesaikan masalah, lakukan langkah-langkah berikut:

Masuk ke server tempat database MySQL yang dikelola sendiri berada.

Jalankan perintah berikut untuk memodifikasi file konfigurasi my.cnf dari database MySQL yang dikelola sendiri:

log_bin=mysql_bin
binlog_format=row
server_id=2 // ID server adalah bilangan bulat lebih besar dari 1. Nilai dalam contoh ini hanya untuk referensi.
binlog_row_image=FULL // Parameter ini diperlukan jika versi database sumber adalah MySQL 5.6 atau lebih baru.

Catatan

Path default file konfigurasi my.cnf adalah /etc/my.cnf. Path sebenarnya mungkin berbeda.

Jalankan perintah berikut untuk memulai ulang database MySQL:
```
[$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
[$Mysql_Dir]/bin/safe_mysqld &
```
Catatan
Ganti [$Mysql_Dir] dengan direktori instalasi database MySQL.
Masuk ke database MySQL yang dikelola sendiri dan jalankan pernyataan SQL berikut untuk memeriksa apakah fitur pencatatan biner diaktifkan:
```
SHOW variables LIKE '%log_bin%';
```
Jika informasi serupa dengan output berikut muncul, fitur pencatatan biner diaktifkan.
Lakukan pra-pemeriksaan lagi di konsol Pemulihan Bencana Data.

Gagal memeriksa format log biner dari database sumber

Skenario: Pemulihan Bencana Data gagal memeriksa format log biner dari database sumber.

Solusi: Item pemeriksaan ini digunakan untuk memeriksa apakah format log biner dari database sumber diatur ke ROW. Jika pemeriksaan gagal, format log biner dari database sumber tidak diatur ke ROW. Untuk menyelesaikan masalah, lakukan langkah-langkah berikut:

Masuk ke server tempat database MySQL yang dikelola sendiri berada.

Ubah file konfigurasi my.cnf dengan cara berikut. Atur parameter binlog_format ke ROW.

log_bin=mysql_bin
binlog_format=ROW  // Atur format log biner ke ROW.
server_id=2 // ID server adalah bilangan bulat lebih besar dari 1. Nilai dalam contoh ini hanya untuk referensi.
binlog_row_image=FULL // Parameter ini diperlukan jika versi database sumber adalah MySQL 5.6 atau lebih baru.

Catatan

Path default file konfigurasi my.cnf adalah /etc/my.cnf. Path sebenarnya mungkin berbeda.

Jalankan perintah berikut untuk memulai ulang database MySQL:
```
[$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
[$Mysql_Dir]/bin/safe_mysqld &
```
Catatan
Ganti [$Mysql_Dir] dengan direktori instalasi database MySQL.
Masuk ke database MySQL yang dikelola sendiri dan jalankan pernyataan SQL berikut untuk memeriksa apakah format log biner diatur ke ROW:
```
SHOW variables LIKE "%binlog_format%";
```
Jika informasi serupa dengan output berikut muncul, format log biner diatur ke ROW.
Lakukan pra-pemeriksaan lagi di konsol Pemulihan Bencana Data.

Gagal memeriksa apakah parameter binlog_row_image dari database sumber diatur ke FULL

Skenario: Pemulihan Bencana Data gagal memeriksa apakah parameter binlog_row_image dari database sumber diatur ke FULL.

Solusi: Item pemeriksaan ini hanya berlaku untuk database MySQL 5.6 atau lebih baru. Item pemeriksaan ini digunakan untuk memeriksa apakah parameter binlog_row_image dari database sumber diatur ke FULL. Jika pemeriksaan gagal, parameter binlog_row_image dari database sumber tidak diatur ke FULL. Akibatnya, file log biner dari database sumber tidak mencatat gambar lengkap. Untuk menyelesaikan masalah, lakukan langkah-langkah berikut:

Masuk ke server tempat database MySQL yang dikelola sendiri berada.

Ubah file konfigurasi my.cnf dengan cara berikut. Atur parameter binlog_row_image ke FULL.

log_bin=mysql_bin
binlog_format=ROW  // Atur format log biner ke ROW.
server_id=2 // ID server adalah bilangan bulat lebih besar dari 1. Nilai dalam contoh ini hanya untuk referensi.
binlog_row_image=FULL // Parameter ini diperlukan jika versi database sumber adalah MySQL 5.6 atau lebih baru.

Catatan

Path default file konfigurasi my.cnf adalah /etc/my.cnf. Path sebenarnya mungkin berbeda.

Jalankan perintah berikut untuk memulai ulang database MySQL:
```
[$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
[$Mysql_Dir]/bin/safe_mysqld &
```
Catatan
Ganti [$Mysql_Dir] dengan direktori instalasi database MySQL.
Masuk ke database MySQL yang dikelola sendiri dan jalankan pernyataan SQL berikut untuk memeriksa apakah parameter binlog_row_image diatur ke FULL:
```
show variables like "%binlog_row_image%";
```
Lakukan pra-pemeriksaan lagi di konsol Pemulihan Bencana Data.

Gagal memeriksa ID server dari database sumber

Skenario: Pemulihan Bencana Data gagal memeriksa ID server dari database sumber.

Solusi: Sebelum tugas migrasi data inkremental dimulai untuk database MySQL, Pemulihan Bencana Data memeriksa nilai parameter server_id dari database sumber. Jika Pemulihan Bencana Data gagal memeriksa nilai parameter server_id dari database MySQL yang dikelola sendiri, lakukan langkah-langkah berikut untuk menyelesaikan masalah:

Masuk ke server database MySQL yang dikelola sendiri dan jalankan pernyataan SQL berikut untuk melihat nilai parameter server_id:
```
SHOW variables LIKE '%server_id%';
```
Jalankan pernyataan SQL berikut untuk memodifikasi nilai parameter server_id. Nilai parameter server_id harus diatur ke bilangan bulat lebih besar dari 1.
```
SET global server_id=[$ID];
```
Catatan
- Ganti [$ID] dengan bilangan bulat lebih besar dari 1. Pastikan nilai yang dimasukkan tidak digunakan oleh database lain.
- Jika database yang dikelola sendiri diterapkan dalam mode utama/sekunder, pastikan replikasi utama-sekunder tidak terpengaruh.
- Setelah pernyataan di atas dijalankan, Anda harus memodifikasi nilai parameter server_id di file konfigurasi. Jika tidak, nilai yang ditentukan untuk parameter server_id menjadi tidak valid setelah database dimulai ulang.
Lakukan pra-pemeriksaan lagi di konsol Pemulihan Bencana Data.

Gagal memeriksa keberadaan file log biner di database sumber

Skenario: Saat memulai jadwal cadangan untuk database MySQL yang dikelola sendiri, Pemulihan Bencana Data gagal memeriksa keberadaan file log biner di database sumber.

Solusi:

Jalankan perintah berikut di MySQL CLI untuk memeriksa apakah fitur pencatatan biner diaktifkan.
```
SHOW variables LIKE 'log_%';
```
Aktifkan fitur pencatatan biner jika fitur tersebut dinonaktifkan. Output perintah berikut menunjukkan bahwa fitur pencatatan biner dinonaktifkan. Dalam hal ini, Anda harus memodifikasi file konfigurasi my.cnf untuk mengaktifkan fitur tersebut. Di server Linux, Anda dapat menjalankan perintah Vim untuk mengedit file konfigurasi.
```
# Pergi ke direktori /etc/my.cnf.
vim /etc/my.cnf

# Tekan tombol I untuk masuk ke mode edit.
# Atur parameter log_bin ke mysql_bin dan tentukan parameter lainnya.
log_bin = mysql_bin
binlog_format = row
server_id = 2
expire_logs_days = 30

# Tekan tombol ESC untuk keluar dari mode edit dan masukkan :wq untuk menyimpan file.
```
Jalankan perintah berikut untuk memulai ulang database MySQL yang dikelola sendiri:
```
systemctl restart mysqld
```
Catatan
Modifikasi pada file konfigurasi berlaku setelah Anda memulai ulang database. Kami sarankan memulai ulang database selama jam-jam sepi.
Setelah memulai ulang database, jalankan perintah di Langkah 1 untuk memeriksa apakah fitur pencatatan biner diaktifkan. Jika ya, mulai ulang jadwal cadangan.

Gagal memeriksa mesin penyimpanan

Solusi: Item pemeriksaan ini digunakan untuk memeriksa apakah mesin penyimpanan dari database sumber mendukung migrasi data inkremental. Mesin penyimpanan FEDERATED dan MRG_MYISAM tidak mendukung migrasi data inkremental antara database MySQL. Jika pemeriksaan gagal, tabel di database sumber mungkin menggunakan salah satu mesin penyimpanan sebelumnya. Lakukan operasi berikut untuk menyelesaikan masalah:

Di halaman Configure Task dari jadwal cadangan, klik Edit Backup Objects. Hapus tabel yang mesin penyimpanannya tidak mendukung migrasi data inkremental dari objek cadangan.

Catatan

Setelah modifikasi berlaku, sistem segera mencadangkan data. Hal ini dapat memengaruhi database sumber dan bisnis Anda. Kami sarankan memodifikasi konfigurasi selama jam-jam sepi.

Gagal memeriksa format kata sandi database MySQL

Skenario: Pra-pemeriksaan gagal untuk jadwal cadangan atau tugas pemulihan saat memulai jadwal cadangan atau tugas pemulihan.

Solusi: Pemulihan Bencana Data memeriksa apakah database MySQL menggunakan format kata sandi versi sebelumnya. Untuk informasi lebih lanjut, lihat old_passwords.

Konflik nama objek

Skenario: Objek pemulihan yang dipilih menggunakan nama yang sama dengan objek yang sudah ada di database tujuan.

Solusi: Buat tugas pemulihan lain dan pilih Rename Object with the Same Name atau klik Edit untuk mengubah nama objek yang akan dipulihkan ke database tujuan. Anda dapat menghapus tugas pemulihan yang gagal.

Kode kesalahan umum yang mungkin dikembalikan untuk fitur unduhan lanjutan

Skenario: Di halaman Backup and Restoration konsol ApsaraDB RDS, Download Instance Backup File dinonaktifkan.

DBS-DownloadTask.Region

Penyebab: Fitur unduhan lanjutan tidak tersedia di wilayah saat ini.

Solusi: Hubungi dukungan teknis di Grup DingTalk (ID 35585947).

DBS-DownloadTask.InstanceInfo

Penyebab: Informasi tentang instance ApsaraDB RDS gagal diperoleh.

Solusi: Periksa apakah instance ApsaraDB RDS tidak normal atau apakah instance tersebut dihapus.

DBS-DownloadTask.DbType

Penyebab: Mesin database dari instance ApsaraDB RDS tidak mendukung fitur unduhan lanjutan.

Solusi: Pastikan mesin database dari instance ApsaraDB RDS adalah MySQL atau PostgreSQL. Fitur ini tidak didukung oleh jenis instance ApsaraDB RDS lainnya.

DBS-DownloadTask.CustinId

Penyebab: Fitur unduhan lanjutan tidak tersedia untuk instance ApsaraDB RDS.

Solusi: Harap tunggu. Fitur unduhan lanjutan tersedia secara bertahap. Anda dapat menghubungi dukungan teknis di Grup DingTalk (ID 35585947).

DBS-DownloadTask.CustinName

Penyebab: Fitur unduhan lanjutan tidak tersedia untuk instance ApsaraDB RDS.

Solusi: Harap tunggu. Fitur unduhan lanjutan tersedia secara bertahap. Anda dapat menghubungi dukungan teknis di Grup DingTalk (ID 35585947).

DBS-DownloadTask.user

Penyebab: Fitur unduhan lanjutan tidak tersedia untuk instance ApsaraDB RDS.

Solusi: Harap tunggu. Fitur unduhan lanjutan tersedia secara bertahap. Anda dapat menghubungi dukungan teknis di Grup DingTalk (ID 35585947).

DBS-DownloadTask.Instance.Version

Penyebab: Versi mesin minor dari instance ApsaraDB RDS tidak memenuhi prasyarat untuk membuat tugas unduhan lanjutan.

Solusi: Versi mesin minor instance ApsaraDB RDS Anda harus lebih baru dari 20201031. Untuk informasi lebih lanjut tentang cara memperbarui versi mesin minor instance ApsaraDB RDS, lihat Perbarui Versi Mesin Minor. Jika Anda mengalami masalah selama pembaruan, hubungi dukungan teknis untuk pengguna ApsaraDB RDS.

Catatan

Untuk informasi lebih lanjut, lihat Unduh File Cadangan.

DBS-DownloadTask.Instance.Storage.Type

Penyebab: Instance ApsaraDB RDS dengan tipe penyimpanan saat ini tidak mendukung fitur unduhan lanjutan.

Solusi: Hanya instance ApsaraDB RDS yang menggunakan SSD standar atau SSD yang ditingkatkan (ESSD) yang mendukung fitur unduhan lanjutan. Anda dapat pergi ke halaman Basic Information konsol ApsaraDB RDS untuk memeriksa tipe penyimpanan instance ApsaraDB RDS.Storage Type

DBS-DownloadTask.Instance.Param

Penyebab: Instance ApsaraDB RDS tidak dikonfigurasikan dengan benar.

Solusi: Pastikan versi mesin minor dari instance ApsaraDB RDS memenuhi prasyarat untuk membuat tugas unduhan lanjutan dan data cadangan tidak dienkripsi. Untuk informasi lebih lanjut, lihat bagian Metode Unduhan dari topik "Unduh File Cadangan".

DBS-DownloadTask

Penyebab: Instance ApsaraDB RDS tidak mendukung fitur unduhan lanjutan.

Solusi: Pastikan instance ApsaraDB RDS memenuhi prasyarat untuk fitur unduhan lanjutan yang dijelaskan dalam topik berikut:

ApsaraDB RDS for MySQL: Unduh File Cadangan Instance ApsaraDB RDS for MySQL
ApsaraDB RDS for PostgreSQL: Unduh File Cadangan Instance ApsaraDB RDS for PostgreSQL

Catatan

Kami sarankan memahami batasan dan catatan penggunaan fitur unduhan lanjutan sebelum menggunakan fitur ini.

Kode kesalahan umum yang mungkin dikembalikan saat menjalankan tugas

DBS-000000

Skenario: Tugas cadangan fisik asli gagal.

Penyebab: Pemulihan Bencana Data tidak dapat terhubung ke server database menggunakan gateway cadangan yang digunakan oleh jadwal cadangan, dan jumlah percobaan ulang telah mencapai batas maksimum 100. Penyebab umum adalah gateway cadangan terputus.

Contoh:

DBS-000000 Penjadwalan gagal, tugas telah dicoba ulang, melebihi batas maksimum

Solusi:

Pergi ke halaman Configure Task dari jadwal cadangan dan periksa apakah gateway cadangan yang digunakan oleh jadwal cadangan dalam keadaan Offline.
Di halaman Backup Gateways, periksa apakah alamat IP, nama host, dan waktu heartbeat terakhir dari gateway cadangan tidak normal.
Periksa status dan konfigurasi jaringan server tempat gateway cadangan diinstal.
Jika server berjalan dengan baik dan jaringan terhubung, Anda dapat mencoba memulai ulang gateway cadangan. Gateway cadangan versi lama mungkin memiliki kerentanan. Tingkatkan gateway cadangan ke versi terbaru. Untuk informasi lebih lanjut, lihat Instal Gateway Cadangan.
Catatan
Jika gateway cadangan tidak dapat dimulai setelah melakukan operasi di atas, hubungi dukungan teknis di Grup DingTalk.

DBS-000001

Skenario: Tugas cadangan logis penuh gagal.

Penyebab: Tugas gagal dan jumlah percobaan ulang telah mencapai batas maksimum.

Contoh:

DBS-000001 Penjadwalan gagal, tugas telah dicoba ulang, melebihi batas maksimum atau tergantung lebih dari 7 jam

Solusi: Coba mulai ulang tugas dan amati status tugas. Jika kesalahan tetap ada, hubungi dukungan teknis di Grup DingTalk.

DBS-000002

Skenario: Tugas cadangan skema logis atau cadangan penuh gagal.

Penyebab: Tidak ada sumber daya layanan yang tersedia.

Contoh:

DBS-000002 Karena sistem saat ini tidak memiliki sumber daya yang tersedia, penjadwalan timeout...

Solusi: Hubungi dukungan teknis di Grup DingTalk.

DBS-000003

Skenario: Sebuah tugas gagal.

Penyebab: Tugas tidak valid.

Contoh:

DBS-000003 Tidak ditemukan instance untuk tugas ini

Solusi: Hubungi dukungan teknis di Grup DingTalk.

DBS-000004

Skenario: Tugas cadangan atau pemulihan fisik gagal.

Penyebab: Tugas cadangan atau pemulihan fisik gagal dijadwalkan saat tugas dimulai.

Contoh:

DBS-000004 + [Pesan Kesalahan]

Solusi: Coba mulai ulang tugas. Jika masalah tetap ada, hubungi dukungan teknis di Grup DingTalk.

DBS-000005

Skenario: Tugas cadangan atau pemulihan logis gagal.

Penyebab: Tugas cadangan atau pemulihan logis dijadwalkan secara tidak normal saat dimulai.

Contoh:

DBS-000005 + [Pesan Kesalahan]

Solusi: Coba mulai ulang tugas yang abnormal. Jika masalah tetap ada, hubungi dukungan teknis di Grup DingTalk.

DBS-000006

Skenario: Timeout terjadi saat memulai tugas cadangan atau pemulihan fisik.

Penyebab: Tugas cadangan atau pemulihan fisik dijadwalkan secara tidak normal saat dimulai, atau sumber daya tidak normal.

Contoh:

DBS-000006 + [Pesan Kesalahan]

Solusi: Coba mulai ulang tugas yang abnormal. Jika masalah tetap ada, hubungi dukungan teknis di Grup DingTalk.

DBS-000007

Skenario: Timeout terjadi saat memulai tugas cadangan atau pemulihan logis.

Penyebab: Tugas cadangan atau pemulihan logis dijadwalkan secara tidak normal saat dimulai, atau sumber daya tidak normal.

Contoh:

DBS-000007 + [Pesan Kesalahan]

Solusi: Coba mulai ulang tugas yang abnormal. Jika masalah tetap ada, hubungi dukungan teknis di Grup DingTalk.

DBS-002003

Skenario: Terjadi kesalahan saat pencadangan fisik asli dilakukan dalam mode cadangan penuh untuk database SQL Server.

Penyebab: Database tidak dapat diakses. Anda mungkin tidak memiliki izin pada database, database tidak ada, atau database tidak dapat diakses.

Contoh:

DBS-002003, pesan: Pengguna tidak memiliki izin untuk mengubah database 'UFTData305999_000002', database tidak ada, atau database tidak dalam keadaan yang memungkinkan pemeriksaan akses.
DBS-002003, pesan: Pengguna tidak memiliki izin untuk mengubah database 'UFDATA
DBS-002003, pesan: Pengguna 'guest' tidak memiliki izin untuk menjalankan DBCC LOGIN
DBS-002003 ["Koneksi TCP/IP ke host localhost, port 1433 gagal. Kesalahan: "Koneksi ditolak: terhubung. Verifikasi properti koneksi, pastikan instance SQL Server berjalan di host dan menerima koneksi TCP/IP di port tersebut, dan tidak ada firewall yang memblokir koneksi TCP ke port tersebut."."].

Solusi:

Periksa apakah database offline. Pastikan database online.
Jika database sedang dipulihkan, tunggu hingga database selesai dipulihkan sebelum memulai tugas lainnya.

Periksa apakah koneksi dienkripsi.

SELECT encrypt_option FROM sys.dm_exec_connections WHERE session_id = @@SPID

Lihat registri untuk memeriksa apakah enkripsi lapisan transport (TLS) diaktifkan.
```
HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.x\Server
## 1.x menunjukkan versi TLS. Contoh: 1.0, 1.1, dan 1.2.
```
Jika item konfigurasi terkait ada dan nilainya adalah 1, enkripsi TLS diaktifkan. Untuk menonaktifkan enkripsi TLS, lakukan langkah-langkah berikut:
1. Ubah nilai item konfigurasi dari 1 menjadi 0.
2. Di Windows, cari Internet Options di kotak pencarian Start. Di kotak dialog Properti Internet, klik tab Advanced dan hapus centang kotak-kotak terkait TLS.
3. Mulai ulang komputer dan mulai ulang tugas cadangan.

DBS-002009

Skenario: Cadangan skema gagal.

Penyebab:

Nama akun database atau kata sandi tidak valid.
Izin akun database diubah, atau database menolak akses dari alamat IP Pemulihan Bencana Data.
Aturan firewall server tempat database diterapkan diubah.
Koneksi jaringan Pemulihan Bencana Data tidak normal. Misalnya, pemetaan jaringan diubah.

Contoh:

DBS-002009 com.alibaba.dts.exception.message.LocalException: DBS-002009 Koneksi db jdbc:mysql://*:*?useSSL=false timeout.

Solusi: Untuk informasi lebih lanjut, lihat bagian "Gagal Menguji Koneksi ke Database Sumber" dari topik ini. Pertama, periksa apakah kegagalan koneksi disebabkan oleh perubahan nama akun database atau kata sandi, izin akun database, alamat IP Pemulihan Bencana Data, atau aturan firewall. Jika item di atas tidak berubah, periksa dan regenerasi pemetaan jaringan.

Pergi ke halaman Configure Task dari jadwal cadangan dan klik Edit Backup Objects.
Masukkan nama akun database dan kata sandi lagi, lalu klik Test Connection.
Selama tes koneksi, sistem memeriksa dan meregenerasi pemetaan jaringan berdasarkan kebutuhan bisnis Anda di latar belakang.
Catatan
Jika database sumber dikonfigurasikan sesuai harapan tetapi tes koneksi masih gagal, hubungi dukungan teknis di Grup DingTalk.
Setelah tes berhasil, klik Next.
Pilih database dan tabel yang ingin dicadangkan dan klik Save untuk menyimpan konfigurasi ke jadwal cadangan.
Setelah mengklik Simpan, konfigurasi di atas mulai berlaku dan Pemulihan Bencana Data segera memulai cadangan. Cadangan ini memengaruhi database sumber dan bisnis Anda. Kami sarankan memodifikasi dan menyimpan konfigurasi selama jam-jam sepi.

DBS-102001

Skenario: Terjadi kesalahan saat tugas dijalankan.

Penyebab: Setelah tugas cadangan selesai, kesalahan dikembalikan saat objek cadangan dilaporkan ke metadatabase. Ini adalah kesalahan umum yang terjadi dalam cadangan skema. Anda dapat memulai ulang tugas untuk memecahkan kesalahan.

Contoh:

DBS-102001 java.lang.IllegalStateException: The RecordSplit must be in FAILED or SUCCE

Solusi: Coba mulai ulang tugas. Jika masalah tetap ada, hubungi dukungan teknis di Grup DingTalk.

DBS-105001

Skenario: Terjadi kesalahan saat tugas dijalankan.

Penyebab: Timeout terjadi saat heartbeat dilaporkan ke metadatabase.

Contoh:

DBS-105001 com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Could not create connection to database server. Attempted reconnect 3 times. Giving up.
com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Terlalu banyak koneksi

Solusi: Coba mulai ulang tugas. Jika masalah tetap ada, hubungi dukungan teknis di Grup DingTalk.

DBS-106001

Skenario: Terjadi kesalahan saat tugas dijalankan.

Penyebab: Terjadi kesalahan internal OSS.

Contoh:

DBS-106001 java.lang.RuntimeException: com.taobao.amp.error.RequestError: Silakan hubungi...
DBS-106001  jumlah tugas error 2 telah mencapai batas maksimum.

Solusi: Hubungi dukungan teknis di Grup DingTalk.

DBS-202002

Skenario: Terjadi kesalahan saat tugas dijalankan untuk mencadangkan data ke Bucket OSS.

Penyebab: Anda memiliki pembayaran tertunda untuk layanan OSS.

Contoh:

DBS-202002 java.io.IOException: com.taobao.amp.error.RequestError: UserDisable

Solusi:

Di halaman Configure Task dari jadwal cadangan, periksa apakah Bucket OSS milik pengguna digunakan sebagai penyimpanan cadangan untuk jadwal cadangan. Jika Bucket OSS milik pengguna digunakan, periksa pembayaran tertunda layanan OSS Anda, perbarui layanan OSS Anda, lalu coba lagi tugas cadangan.
Jika Anda tidak menggunakan Bucket OSS milik pengguna, hubungi dukungan teknis di Grup DingTalk.

DBS-203101

Skenario: Terjadi kesalahan saat pencadangan fisik asli dilakukan dalam mode cadangan penuh untuk database SQL Server.

Penyebab:

Database tidak berfungsi lagi.
Enkripsi SSL diaktifkan untuk database.

Contoh:

DBS-203101 Kegagalan koneksi db

Solusi:

Gunakan SQL Server Management Studio (SSMS) untuk masuk ke database SQL Server menggunakan nomor port database. Periksa apakah database ada atau sedang berjalan.
Secara default, Anda dapat masuk ke database tanpa menggunakan nomor port. Misalnya, localhost,1433 dipisahkan oleh koma (,).
Catatan
Pemulihan Bencana Data hanya mendukung koneksi TCP ke database.
Pastikan enkripsi SSL dinonaktifkan untuk database saat ini.

DBS-203102

Skenario: Terjadi kesalahan saat pencadangan fisik asli dilakukan dalam mode cadangan penuh untuk database SQL Server.

Penyebab:

Database dihapus.
Database diubah namanya.
Database dalam keadaan abnormal dan tidak dapat dicadangkan.

Contoh:

DBS-203102 Tidak dapat menemukan database ......

Solusi:

Periksa apakah database dihapus. Jika database dihapus, konfigurasikan ulang objek cadangan.
Pergi ke halaman Configure Task dari jadwal cadangan, klik Edit Backup Objects, lalu konfigurasikan objek cadangan.
Catatan
Cadangan segera dimulai setelah objek cadangan yang dikonfigurasi ulang disimpan dan mulai berlaku. Perhatikan dampaknya pada bisnis Anda dan database sumber.
Periksa apakah database diubah namanya. Jika database diubah namanya, lihat langkah sebelumnya untuk mengonfigurasi ulang objek cadangan.
Periksa apakah database offline. Pastikan database online.
Jika database sedang dipulihkan, tunggu hingga database selesai dipulihkan sebelum memulai tugas lainnya.
Jika fitur auto-close diaktifkan untuk database, atur fitur auto-close ke False.

DBS-203103

Skenario: Terjadi kesalahan saat pencadangan fisik asli dilakukan dalam mode cadangan penuh untuk database SQL Server.

Penyebab: Database tidak tersedia.

Contoh:

DBS-203103 Server database sudah dimatikan

Solusi: Jadikan database tersedia.

DBS-203104

Skenario: Terjadi kesalahan saat pencadangan fisik asli dilakukan dalam mode cadangan penuh untuk database SQL Server.

Penyebab: Masalah terjadi pada komponen infrastruktur desktop virtual (VDI).

Contoh:

DBS-203104 Tunggu VDI timeout 30 detik

Solusi: Kami sarankan memeriksa acara Windows untuk memecahkan masalah komponen VDI dan mulai ulang tugas setelah masalah diselesaikan. Jika tidak ada pengecualian yang ditemukan dalam pemeriksaan, Anda dapat mencoba menunggu beberapa saat lalu mencoba cadangan lagi. Jika kesalahan tetap ada, hubungi dukungan teknis di Grup DingTalk.

DBS-203201

Skenario: Terjadi kesalahan saat pencadangan fisik asli dilakukan dalam mode cadangan penuh untuk database SQL Server.

Penyebab:

Beberapa tugas cadangan dijalankan secara bersamaan untuk mencadangkan basis data yang sama.
Hal ini disebabkan oleh pemotongan log. Penyebab potensial dari pemotongan log meliputi:
- Alat cadangan lain sedang mencadangkan basis data di sisi pengguna, menyebabkan pemotongan log.
- Pengguna memperkecil basis data, menyebabkan pemotongan log.
- Pengguna telah menyesuaikan model pemulihan basis data.
- Perilaku lain yang dapat menyebabkan pemotongan log.

Contoh:

DBS-203201 database xxx backupable lsn {1} melebihi batas {2}

database XXXXXX backupable lsn 10000000000000000009 melebihi batas 10000000000000000001,,already increment backup name:,backup datetime:2024-01-19 00:00:00

Solusi:

Beberapa tugas cadangan dijalankan untuk mencadangkan database pada saat yang sama.
- Jika beberapa tugas cadangan dijalankan untuk mencadangkan database pada saat yang sama, pertahankan hanya satu tugas cadangan pada satu waktu dan hentikan tugas cadangan lainnya.
- Jika skrip digunakan untuk mencadangkan database secara terjadwal, hentikan tugas cadangan lainnya untuk memastikan hanya satu tugas cadangan yang dijalankan untuk mencadangkan database pada satu waktu.
- Jika pencadangan inkremental dilakukan untuk beberapa database, beberapa database mungkin gagal dicadangkan. Dalam hal ini, nonaktifkan pencadangan inkremental lalu aktifkan kembali pencadangan inkremental.
Ini disebabkan oleh pemotongan log.
- Cadangan tidak lengkap karena log dipotong. Kami sarankan memulai kembali cadangan penuh di konsol.

DBS-203202

Skenario: Terjadi kesalahan saat pencadangan fisik asli dilakukan dalam mode cadangan penuh untuk database SQL Server.

Penyebab:

Pencadangan inkremental dilakukan sebelum pencadangan penuh dilakukan. Masalah ini mungkin terjadi saat Anda mengonfigurasi tugas cadangan untuk pertama kali.
Masalah ini juga mungkin terjadi jika opsi CopyOnly dipilih saat mengonfigurasi tugas cadangan.

Contoh:

DBS-203202 BACKUP LOG {0} tidak dapat dilakukan karena tidak ada cadangan database saat ini

Solusi: Anda dapat secara manual melakukan cadangan penuh lalu memulai ulang tugas pencadangan inkremental yang gagal untuk tugas cadangan.

DBS-203203

Skenario: Terjadi kesalahan saat pencadangan fisik asli dilakukan dalam mode cadangan penuh untuk database SQL Server.

Penyebab: Log transaksi tidak dapat dicadangkan karena Anda tidak menggunakan model pemulihan FULL.

Contoh:

DBS-203203 Hanya mendukung pencadangan log transaksi inkremental dalam MODE FULL, database {0}

Solusi: Jalankan pernyataan SQL berikut untuk mengatur model pemulihan ke FULL:

ALTER DATABASE [xxx] SET RECOVERY FULL

DBS-203205

Skenario: Terjadi kesalahan saat pencadangan fisik asli dilakukan dalam mode cadangan penuh untuk database SQL Server.

Penyebab: Database dalam keadaan offline.

Contoh:

DBS-203205 status database adalah; DBS-203205 status database AIS20210425120342 adalah {1}

Solusi:

Periksa apakah database offline. Pastikan database online.
Jika database sedang dipulihkan, tunggu hingga database selesai dipulihkan sebelum memulai tugas lainnya.

DBS-203206

Skenario: Terjadi kesalahan saat pencadangan fisik asli dilakukan dalam mode cadangan penuh untuk database SQL Server.

Penyebab: Database tidak dapat diakses. Database mungkin rusak. Anda harus memeriksa apakah database tersedia.

Contoh:

DBS-203206 pesan:Database 'UFTData992044_000002' tidak dapat dibuka karena

Solusi:

Periksa apakah database offline. Pastikan database online.
Jika database sedang dipulihkan, tunggu hingga database selesai dipulihkan sebelum memulai tugas lainnya.

DBS-203240

Skenario: Terjadi kesalahan saat pencadangan fisik asli dilakukan dalam mode cadangan penuh untuk database SQL Server.

Penyebab: Akun database saat ini tidak memiliki izin administrator sistem.

Contoh:

DBS-203240, pesan:Pengguna 'guest' tidak memiliki izin untuk menjalankan DBCC LOGIN

Solusi: Ubah konfigurasi jadwal cadangan. Gunakan akun database yang memiliki izin yang diperlukan atau tetapkan peran administrator sistem ke akun database yang digunakan. Untuk informasi lebih lanjut tentang cara mengubah akun database, lihat Bagaimana Cara Memodifikasi Database Sumber Cadangan?

DBS-203301

Skenario: Terjadi kesalahan saat pencadangan fisik asli dilakukan dalam mode pemulihan penuh untuk database SQL Server.

Penyebab: Log ekor belum dicadangkan. Untuk mencegah kehilangan data, Anda harus mencadangkan log ekor dari database saat ini sebelum memulihkan database.

Catatan

Log ekor adalah log transaksi yang dihasilkan setelah cadangan log terakhir.

Contoh:

DBS-203301 Ekor log untuk database {0} belum dicadangkan. Gunakan BACKUP LOG WITH NORECOVERY untuk mencadangkan log jika berisi pekerjaan yang tidak ingin Anda hilangkan. Gunakan klausa WITH REPLACE atau WITH STOPAT dari pernyataan RESTORE untuk menimpa isi log saja.

Solusi:

Jalankan perintah berikut untuk mencadangkan log ekor:

BACKUP LOG [Nama database yang ingin Anda pulihkan] TO DISK='C:\backupdir\moyun_test.trn' WITH NORECOVERY;

Mulai ulang tugas pemulihan penuh yang gagal.

DBS-203302

Skenario: Terjadi kesalahan saat melakukan backup fisik penuh untuk database SQL Server.

Penyebab: Set cadangan penuh tidak dapat digunakan untuk memulihkan data karena log transaksi terakhir LSN {0} dalam set cadangan penuh saat ini dihasilkan lebih awal daripada log transaksi LSN {1} dalam set cadangan penuh lainnya.

Contoh:

DBS-203302 log dalam set cadangan ini berakhir pada LSN {0}, yang terlalu dini untuk diterapkan ke database. Cadangan log yang lebih baru yang mencakup LSN {1} dapat dipulihkan.

Solusi: Hubungi dukungan teknis di Grup DingTalk.

DBS-301005

Skenario: Terjadi kesalahan saat melakukan pencadangan fisik dalam mode cadangan penuh untuk database Oracle.

Penyebab: Mode ARCHIVELOG dinonaktifkan pada database Oracle. Aktifkan terlebih dahulu mode ARCHIVELOG untuk database Oracle.

Contoh:

DBS-301005, pesan:INNER_ERROR[301005]:database tidak dalam mode arsip
DBS-301005, pesan:INNER_ERROR[301005]:user="" ConnectString="" standalone params= ......

Solusi: Aktifkan mode arsip. Untuk informasi lebih lanjut, lihat Aktifkan mode arsip.

DBS-301502

Skenario: Terjadi kesalahan saat pencadangan fisik dilakukan untuk database MySQL.

Penyebab: Operasi DDL tidak dapat direkam dalam log redo selama pencadangan.

Contoh:

DBS-301502, tanpa pencatatan redo

Solusi: Mulai ulang tugas cadangan saat operasi DDL tidak dilakukan.

DBS-301503

Skenario: Terjadi kesalahan saat pencadangan fisik dilakukan untuk database MySQL.

Penyebab: Kecepatan pembuatan log redo melebihi kecepatan pencadangan.

Contoh:

DBS-301503, penyalinan log terlalu lambat

Solusi: Kami sarankan meningkatkan kapasitas file redo dan melakukan pencadangan selama jam-jam sepi.

DBS-301504

Skenario: Terjadi kesalahan saat pencadangan fisik dilakukan untuk database MySQL.

Penyebab: Enkripsi diaktifkan untuk tabel di database MySQL. Pemulihan Bencana Data tidak mendukung pencadangan tabel yang dienkripsi.

Contoh:

DBS-301504, kehilangan enkripsi

Solusi: Kami sarankan menonaktifkan fitur enkripsi untuk tabel dan mulai ulang tugas cadangan. Jika Anda tidak ingin menonaktifkan fitur enkripsi dan ingin berhenti menggunakan Pemulihan Bencana Data, hubungi staf layanan pelanggan Pemulihan Bencana Data untuk menjelaskan alasan dan mengajukan pengembalian dana untuk jadwal cadangan.

DBS-301505

Skenario: Terjadi kesalahan saat pencadangan fisik dilakukan untuk database MySQL.

Penyebab: Proses pencadangan dihentikan oleh sistem.

Contoh:

DBS-301505, signal: dihentikan

Solusi: Mulai ulang tugas.

DBS-302035

Skenario: Terjadi kesalahan saat pencadangan fisik dilakukan dalam mode cadangan penuh untuk database Oracle.

Penyebab: Informasi peran database instance Oracle tidak dapat diperoleh.

Contoh:

DBS-302035 USER_CAN_NOT_LOAD_INSTANCE_ROLE[302035]

Solusi:

Masuk ke server tempat instance database diterapkan.
Jalankan perintah berikut untuk masuk ke database sebagai administrator sistem:
```
sqlplus / as sysdba
```
Jalankan pernyataan SQL berikut untuk memeriksa apakah hasil dikembalikan:
```
select database_role from v$database;
```
Jika tidak ada hasil yang dikembalikan, pecahkan masalah tersebut. Jika hasil dikembalikan, hubungi dukungan teknis di Grup DingTalk.

DBS-400001

Skenario: Terjadi kesalahan saat pencadangan fisik asli dilakukan dalam mode cadangan penuh dan data cadangan dikonversi.

Penyebab: Spesifikasi jadwal cadangan tidak memenuhi kebutuhan bisnis Anda.

Contoh:

DBS-400001 , pesan :Java heap space.
DBS-400001 java.lang.OutOfMemoryError: Java heap space

Solusi: Kami sarankan meningkatkan spesifikasi jadwal cadangan. Jika Anda perlu sementara meningkatkan batas memori untuk tugas mendesak seperti tugas pemulihan, hubungi dukungan teknis di Grup DingTalk. Untuk informasi lebih lanjut tentang cara meningkatkan spesifikasi jadwal cadangan, lihat Tingkatkan Jadwal Cadangan.

DBS-999999 atau tanpa kode kesalahan

Skenario: Terjadi kesalahan saat tugas dijalankan.

Penyebab: Pengecualian belum didefinisikan oleh Pemulihan Bencana Data, atau kode kesalahan telah didefinisikan untuk pengecualian tetapi kode kesalahan tidak ditampilkan.

Contoh:

DBS-999999 + [Pesan Kesalahan]

Solusi: Kami sarankan menyalin pesan kesalahan dan mencari kesalahan tersebut dalam topik ini untuk memeriksa apakah masalah tersebut didefinisikan dengan kode kesalahan lain. Jika Anda tidak dapat menemukan kesalahan yang relevan dalam topik ini, hubungi dukungan teknis di Grup DingTalk.