Server MySQL di bagian ketiga Microsoft Azure (pencadangan dan pemulihan)

Database


Database Azure untuk MySQL

pengantar

Blog ini adalah bab ketiga tentang penerapan infrastruktur MySQL di cloud Azure. Selain performa, sebenarnya kita perlu mempertimbangkan kemampuan backup dan recovery. Tujuan blog ini adalah untuk menyajikan fasilitas pencadangan dan pemulihan utama yang disediakan oleh Azure melalui contoh sederhana dan untuk mendemonstrasikan fasilitas pencadangan/pemulihan kedua menggunakan alat dump MySQL Shell.

Jendela dan mekanisme cadangan

Azure untuk MySQL yang fleksibel membuat periode penyimpanan cadangan server 7 hari secara default. Masa penyimpanan ini dapat diperpanjang hingga 35 hari atau dipersingkat hingga 1 hari. Selain itu, kami dapat memutuskan apakah Anda menginginkan penyimpanan cadangan Geo Redundant. Secara default, pencadangan secara lokal berlebihan.

Penting untuk dipahami bahwa Azure mencadangkan seluruh server, bukan hanya Server MySQL melalui mysqldump, Pencadangan Perusahaan MySQL, atau solusi lainnya. Cadangan ini hanya dapat digunakan untuk memulihkan Server MySQL ke Database Azure lain untuk Server MySQL. Ini berarti bahwa cadangan ini tidak dapat diekspor untuk membuat database baru di server internal kami. Jika kita ingin mengekstrak bagian dari database kita untuk ekspor data, kita dapat menggunakan mysqldump, utilitas dump sampel MySQL Shell, atau toolset yang disediakan oleh MySQL Shell.

Pengaturan periode pemeliharaan cadangan dan opsi redundansi

Cadangan yang disediakan oleh Azure dapat digunakan untuk pemulihan Point In Time server dengan perincian 5 menit karena snapshot sistem diambil secara otomatis setiap 5 menit. Sebagaimana ditentukan dalam dokumentasi, cadangan dienkripsi menggunakan AES 256-bit.

Biaya pencadangan dan pemulihan

Seperti yang dijelaskan di situs web Microsoft

“Penyimpanan cadangan adalah ruang penyimpanan yang terkait dengan pencadangan server Anda secara otomatis. Meningkatkan periode penyimpanan cadangan meningkatkan ruang penyimpanan cadangan yang digunakan oleh server Anda. Tidak ada biaya tambahan untuk penyimpanan cadangan hingga 100% dari total penyimpanan server Anda. Penggunaan penyimpanan cadangan tambahan dibebankan dalam gigabyte per bulan. – https://azure.microsoft.com/en-us/pricing/details/mysql/flexible-server/

Peningkatan pemeliharaan cadangan dapat memengaruhi harga. Kami dapat melacak biaya global untuk Azure Database untuk MySQL di URL berikut: https://azure.microsoft.com/en-us/pricing/details/mysql/flexible-server/

Pulihkan database dari antarmuka Pemulihan Cadangan Azure

Dalam percobaan pertama ini, kami hanya akan menggunakan kemampuan pemulihan yang disediakan oleh Azure Database untuk server fleksibel MySQL. Kami mensimulasikan kesalahan pengguna dengan menjatuhkan tabel dan memulihkan seluruh server (karena tidak mungkin hanya memulihkan database atau tabel menggunakan properti Azure).

  1. Salah melempar meja
 MySQL  albatroz.mysql.database.azure.com:3306 ssl  SQL > SELECT CURRENT_TIMESTAMP ;
+---------------------+
| CURRENT_TIMESTAMP   |
+---------------------+
| 2022-08-18 20:48:44 |
+---------------------+
1 row in set (0.1002 sec)
 MySQL  albatroz.mysql.database.azure.com:3306 ssl  SQL > drop table sysbench.sbtest1;
Query OK, 0 rows affected (0.1884 sec)
  1. Kembalikan server MySQL ke waktu sebelum kesalahan

Pertama, kita perlu pergi ke menu “Backup/Restore” Azure Database untuk MySQL Flexible Server dan pilih backup yang ingin kita pulihkan. Seperti yang kita lihat, pencadangan dilakukan setiap hari. Dalam situasi kami saat ini, kami ingin menggunakan versi cadangan terbaru (Auto Backup #5).

Azure Database untuk MySQL Flexible Server Backup Suite

Setelah memilih cadangan, akan muncul halaman yang menunjukkan opsi server pemulihan. Ini memungkinkan kami untuk membuat pemulihan point-in-time (PITR) dari server kami dengan memilih di antara 3 opsi:

  • Titik pemulihan terakhir (sekarang)
  • Pilih titik pemulihan khusus
  • Memilih restore point tercepat (restore menggunakan full backup)

Dalam kasus kami, kami akan menggunakan “Pilih titik pemulihan khususpilihan seperti pada gambar di bawah ini. Kami menentukan waktu pemulihan khusus sebelum kesalahan dan menentukan nama untuk server yang dipulihkan.

Pulihkan server menggunakan titik pemulihan khusus

Setelah pemulihan diminta, dibutuhkan sekitar 5 menit untuk menyebarkan server baru.

  1. Mari kita periksa apakah meja saya digunakan di server baru

Akhirnya kita hanya perlu terhubung ke server yang baru dipulihkan dan memeriksa apakah tabel yang dihapus sudah kembali. Tentu saja, kita juga dapat mengekspor tabel ini dari server yang dipulihkan ini dan mengimpor tabel yang sama ke server utama menggunakan mysqldump.

 MySQL  albatrozrestored.mysql.database.azure.com:3306 ssl  sysbench  SQL > show tables from sysbench like '%1';
+-------------------------+
| Tables_in_sysbench (%1) |
+-------------------------+
| sbtest1                 |
+-------------------------+
1 row in set (0.1048 sec)

4. Ekspor/impor tabel dari server yang dipulihkan

Sekarang setelah server dipulihkan, kami dapat mengekspor tabel yang salah dihapus dengan menggunakannya util.dumpTables() dan menggunakannya untuk masuk ke server albatroz util.loadDump(). Prosesnya sangat sederhana seperti yang Anda lihat di bawah ini:

Ekspor dari server yang dipulihkan (Albatros yang Direkonstruksi)

MySQL  albatrozrestored.mysql.database.azure.com:3306 ssl  sysbench  JS > util.dumpTables("sysbench", [ "sbtest1"], "C:/Users/grs/Albatroz-Sysbench-sbtest1");
NOTE: Backup lock is not available to the account 'grs'@'%' and DDL changes will not be blocked. The dump may fail with an error if schema changes are made while dumping.
Acquiring global read lock
Global read lock acquired
Initializing - done
...
...
109% (15.29K rows / ~13.98K rows), 0.00 rows/s, 0.00 B/s uncompressed, 0.00 B/s compressed
Dump duration: 00:00:01s
Total duration: 00:00:06s
Schemas dumped: 1
Tables dumped: 1
Uncompressed data size: 2.93 MB
Compressed data size: 1.33 MB
Compression ratio: 2.2
Rows written: 15294
Bytes written: 1.33 MB
Average uncompressed throughput: 2.35 MB/s
Average compressed throughput: 1.07 MB/s

Impor di server Albatros

MySQL  albatroz.mysql.database.azure.com:3306 ssl  JS > util.loadDump("C:/Users/grs/Albatroz-Sysbench-sbtest1", {schema: "sysbench"});
Loading DDL and Data from 'C:/Users/grs/Albatroz-Sysbench-sbtest1' using 4 threads.
Opening dump...
Target is MySQL 8.0.28. Dump was produced from MySQL 8.0.28
Scanning metadata - done
Checking for pre-existing objects...
Executing common preamble SQL
Executing DDL - done
Executing view DDL - done
Starting data load
1 thds loading | 100% (2.93 MB / 2.93 MB), 1.94 MB/s, 0 / 1 tables done
Executing common postamble SQL
Recreating indexes - done
1 chunks (15.29K rows, 2.93 MB) for 1 tables in 1 schemas were loaded in 6 sec (avg throughput 1.94 MB/s)
0 warnings were reported during the load.

Pulihkan basis data dari cadangan Andas

Seperti disebutkan dalam pendahuluan, dalam bab ini saya akan menyajikan solusi pencadangan/pengembalian pelengkap. Tentu saja, Azure tidak mencegah Anda melakukan pencadangan sendiri dengan menyambungkan ke Azure Database untuk Server Fleksibel MySQL dan menggunakan Mysqdump, Pencadangan Perusahaan MySQL, atau solusi pencadangan MySQL lainnya. Saya memutuskan untuk mengambil kesempatan blog ini untuk menggunakan alat cadangan yang disediakan oleh MySQL Shell. Bahkan, utilitas dump sampel MySQL Shell, mis util.dumpInstance(), util.dumpSchemas() atau bahkan util.dumpTables(), diperkenalkan di MySQL Shell 8.0.22, menawarkan fitur menarik. Alat ekspor ini sendiri layak mendapatkan beberapa blog yang didedikasikan untuk itu.

Sebelum kita mulai, mari kita jelaskan apa yang akan ditampilkan dalam beberapa baris berikutnya:

Pemulihan tabel MySQL setelah kesalahan manusia
  1. Langkah pertama melibatkan melakukan dump dari instance MySQL
  2. Pada langkah kedua, kami menyisipkan baris dalam tabel yang disebut sbtest1
  3. Ketiga, kami mensimulasikan kesalahan manusia dan membuat tabel
  4. Kemudian pulihkan database ke status setelah pencadangan
  5. Setelah memulihkan cadangan, kami menjalankan biner ke status sebelum kesalahan manusia
  6. Akhirnya kami akan memeriksa apakah sisipan terakhir saya disimpan di sbtest2
  1. Menjatuhkan instance MySQL menggunakan util.dumpInstance()

Seperti dijelaskan di atas, langkah pertama melibatkan melakukan dump dari seluruh sampel. Tanpa cadangan ini, kami tidak dapat memulihkan database. Kami akan menggunakan util.dumpInstance() Seperti yang diberikan di bawah ini:

MySQL  albatroz.mysql.database.azure.com:3306 ssl  JS > util.dumpInstance("C:/Users/grs/AlbatrozDump", {dryRun: false, showProgress: true, threads: 2})
NOTE: Backup lock is not available to the account 'grs'@'%' and DDL changes will not be blocked. The dump may fail with an error if schema changes are made while dumping.
Acquiring global read lock
Global read lock acquired
Initializing - done
2 out of 6 schemas will be dumped and within them 9 tables, 0 views.
4 out of 7 users will be dumped.
...
...
107% (137.28K rows / ~128.10K rows), 14.42K rows/s, 2.61 MB/s uncompressed, 1.20 MB/s compressed
Dump duration: 00:00:15s
Total duration: 00:00:21s
Schemas dumped: 2
Tables dumped: 9
Uncompressed data size: 26.26 MB
Compressed data size: 11.97 MB
Compression ratio: 2.2
Rows written: 137284
Bytes written: 11.97 MB
Average uncompressed throughput: 1.72 MB/s
Average compressed throughput: 784.25 KB/s
  1. Memasukkan baris ke tabel kita

Sekarang kami mensimulasikan beberapa aktivitas dalam database dengan menyisipkan baris dalam tabel sbtest1.

MySQL  albatroz.mysql.database.azure.com:3306 ssl  sysbench  SQL > insert into sbtest1 values(999999999,1,1,"my row before drop table");
Query OK, 1 row affected (0.1134 sec)
MySQL  albatroz.mysql.database.azure.com:3306 ssl  sysbench  SQL > SELECT CURRENT_TIMESTAMP ;
+---------------------+
| CURRENT_TIMESTAMP   |
+---------------------+
| 2022-08-19 16:42:12 |
+---------------------+
  1. Salah melempar meja

Ketiga, kami mensimulasikan kesalahan manusia dengan menjatuhkan tabel sbtest1.

 MySQL  albatroz.mysql.database.azure.com:3306 ssl  sysbench  SQL > SELECT CURRENT_TIMESTAMP ;
+---------------------+
| CURRENT_TIMESTAMP   |
+---------------------+
| 2022-08-19 16:46:47 |
+---------------------+
1 row in set (0.1095 sec)
 MySQL  albatroz.mysql.database.azure.com:3306 ssl  sysbench  SQL > drop table sysbench.sbtest1;
Query OK, 0 rows affected (0.1823 sec)
  1. Pulihkan server MySQL menggunakan cadangan

Sekarang kita perlu memulihkan database menggunakan cadangan terbaru kami. Kami akan menggunakan util.loadDump() Untuk memulihkan tabel, kita cukup menggunakan opsi “” untuk memulihkan tabelTermasuk meja“.

 MySQL  albatroz.mysql.database.azure.com:3306 ssl  sysbench  JS > util.loadDump("C:/Users/grs/AlbatrozDump", { includeTables: ["sysbench.sbtest1"],loadDdl:true, LoadData:true, threads: 2})
Loading DDL and Data from 'C:/Users/grs/AlbatrozDump' using 2 threads.
Opening dump...
Target is MySQL 8.0.28. Dump was produced from MySQL 8.0.28
Scanning metadata - done
Checking for pre-existing objects...
Executing common preamble SQL
Executing DDL - done
Executing view DDL - done
Starting data load
1 thds loading \ 100% (2.93 MB / 2.93 MB), 1.16 MB/s, 0 / 1 tables done
Executing common postamble SQL
Recreating indexes - done
1 chunks (15.29K rows, 2.93 MB) for 1 tables in 1 schemas were loaded in 9 sec (avg throughput 1.16 MB/s)
0 warnings were reported during the load.

Jika pemulihan bekerja dengan benar, tabel sbtest1 Itu harus dibangun kembali. Kami sekarang telah memulihkan tabel sbtest1 Tidak ada kueri yang dieksekusi setelah itu (sebelum tabel drop).

 MySQL  albatroz.mysql.database.azure.com:3306 ssl  sysbench  SQL > show tables;
+--------------------+
| Tables_in_sysbench |
+--------------------+
| sbtest1            |
| sbtest10           |
| sbtest2            |
| sbtest3            |
| sbtest4            |
| sbtest5            |
| sbtest6            |
| sbtest7            |
| sbtest8            |
| sbtest9            |
+--------------------+
10 rows in set (0.1169 sec)

MySQL  albatroz.mysql.database.azure.com:3306 ssl  sysbench  SQL > select * from sbtest1 where pad like 'my%';
Empty set (0.1284 sec)
  1. Eksekusi log biner

Sebelum menjalankan log biner, kita perlu mendefinisikan apa yang kita “panggil”.titik awal” Dan “Posisi akhir“. Untuk menemukan dua angka ini, kita perlu mencari posisi log setelah backup dan menemukan posisi log “drop table”. Yang pertama (titik awal) dapat ditemukan di metadata dump (file .json). Untuk yang kedua kita perlu mencari posisi yang tepat menggunakan mysqlbinlog seperti yang ditunjukkan di bawah ini (posisi jatuh di 14329648)

mysqlbinlog --verify-binlog-checksum --host=albatroz.mysql.database.azure.com --port=3306 --user=grs -p -                                                   -read-from-remote-server --verbose --start-datetime="2022-08-19 18:40:40" --stop-datetime="2022-08-19 18:50:47" mysql-bin.00                                                   0006 | grep -C 15 "DROP TABLE"

# at 14329648
#220819 18:47:12 server id 3691359094  end_log_pos 14329725 CRC32 0xa81066cf    Anonymous_GTID  last_committed=6652     sequence_number=6653r                                  br_only=no      original_committed_timestamp=1660927632152016   immediate_commit_timestamp=1660927632152016     transaction_length=217
# original_commit_timestamp=1660927632152016 (2022-08-19 18:47:12.152016 CEST)
# immediate_commit_timestamp=1660927632152016 (2022-08-19 18:47:12.152016 CEST)
/*!80001 SET @@session.original_commit_timestamp=1660927632152016*//*!*/;
/*!80014 SET @@session.original_server_version=80028*//*!*/;
/*!80014 SET @@session.immediate_server_version=80028*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 14329725
#220819 18:47:12 server id 3691359094  end_log_pos 14329865 CRC32 0x9f7865b0    Query   thread_id=480   exec_time=0     error_code=0    Xid =                                   412469
use `sysbench`/*!*/;
SET TIMESTAMP=1660927632/*!*/;
DROP TABLE `sbtest1` /* generated by server */
/*!*/;

Sekarang kita memiliki posisi awal dan akhir dari log biner, kita dapat menerapkan peristiwa file log biner ke server. Untuk bagian saya, saya lebih suka melalui langkah perantara yang melibatkan pembuatan file yang berisi semua acara. Dengan begitu saya bisa melihat apa yang ada di dalamnya dan kemudian menjalankan file saya. Ini memungkinkan saya, misalnya, untuk melihat apakah saya telah membuat kesalahan. Misalnya, saya dapat mewakili “Saya” seperti yang ditunjukkan di bawah inimemasukkan” Penyataan:

[email protected]:~$  mysqlbinlog --verify-binlog-checksum --host=albatroz.mysql.database.azure.com --port=3306 --user=grs -p --read-from-remote-server --start-datetime="2022-08-19 16:40:40" --stop-datetime="2022-08-19 16:46:47" mysql-bin.000006 >/tmp/restore.sql
Enter password:
[email protected]:~$ vi /tmp/restore.sql
...
# at 14329545
#220819 18:41:18 server id 3691359094  end_log_pos 14329617 CRC32 0xd124e6a0    Write_rows: table id 913 flags: STMT_END_F

BINLOG '
Lr3/YhN2qwXcRQAAAMmm2gAAAJEDAAAAAAEACHN5c2JlbmNoAAdzYnRlc3QxAAQDA/7+BO7g/vAA
AQEAAgP8/wDqexN/
Lr3/Yh52qwXcSAAAABGn2gAAAJEDAAAAAAEAAgAE/wD/yZo7AQAAAAEAMRhteSByb3cgYmVmb3Jl
IGRyb3AgdGFibGWg5iTR
'/*!*/;
### INSERT INTO `sysbench`.`sbtest1`
### SET
###   @1=999999999
###   @2=1
###   @3='1'
###   @4='my row before drop table'
# at 14329617
...

Akhirnya, kami dapat menjalankan skrip pemulihan kami di database.

[email protected]:~$ mysql --host=albatroz.mysql.database.azure.com --port=3306 --user=grs -p </tmp/restore.sql
Enter password:
  1. Mari kita periksa apakah sisipan terakhir kita dieksekusi

Seperti yang kita lihat, record terakhir yang kita masukkan ke dalam tabel sekarang tersedia.

 MySQL  albatroz.mysql.database.azure.com:3306 ssl  sysbench  SQL > select * from sbtest1 where pad like 'my%';
+-----------+---+---+--------------------------+
| id        | k | c | pad                      |
+-----------+---+---+--------------------------+
| 999999999 | 1 | 1 | my row before drop table |
+-----------+---+---+--------------------------+

Hasil

Antarmuka Azure Backup Restore menyediakan solusi yang mudah dan menarik untuk mencadangkan dan memulihkan server MySQL melalui replikasi server. Selain tes yang saya lakukan, penerapan server baru relatif cepat. Namun, server saya tidak berisi gigabyte data. Bergantung pada kebutuhan Anda, jendela pencadangan 35 hari mungkin tampak terlalu kecil.

Selain solusi ini, saya sangat menganjurkan administrator basis data untuk terus mencadangkan basis data MySQL mereka menggunakan alat lain seperti yang disediakan oleh MySQL Shell atau solusi pencadangan lainnya untuk memastikan bahwa tidak ada transaksi yang tidak hilang saat data dipulihkan. Solusi tersebut dapat memberikan fleksibilitas yang lebih besar dalam proses pencadangan dan pemulihan serta retensi yang lebih lama.


Pasca kunjungan:
152



Source link

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan. Ruas yang wajib ditandai *