作者介紹
劉書浩，中國移動DBA，負責“移動雲”業務系統的資料庫運維、标準化等工作；擅長MySQL技術領域，熟悉MySQL複制結構、Cluster架構及運維優化；具有自動化運維經驗，負責“移動雲”資料庫管理平台的搭建。
前言
資料是企業重要的生産資料，并且往往是不可再生的，關鍵資料（客戶訂購、交易和生産資訊等）丢失會使企業陷入困境，為了應對資料丢失造成的損失，必須對重要資料進行災備保護。
一般資料從産生到存儲，主要經過應用、中間件、資料庫、作業系統、磁驅動、伺服器硬體、網絡交換機再到存儲。其中資料庫環節的災備保護尤為重要，"移動雲"為資料提供的災備恢複機制包括備份和容災。
其中，備份主要是指為業務系統産生的重要客戶資料制作一份或者多份拷貝，以增強資料的安全性。
容災則是指在相隔較遠的兩地（“移動雲”為廣州和北京兩地）建立兩套或多套功能相同的業務系統，互相之間可以進行健康狀态監視和功能切換。當一處系統因裝置故障、人為意外或自然災害等不可抗力停止工作時，整套業務系統可以切換到另一處，使得該系統功能仍可以繼續正常工作，客戶能夠正常通路。
首先，來看一下資料庫備份。
備份
對于“移動雲”資料庫運維人員來說，資料庫的備份與恢複是日常運維中最常見的工作之一。在資料庫運維的過程中，經常會遇到伺服器當機、磁盤損壞和人工誤操作等情況，在這種情況下，要保證資料不丢失、或者最小程度的丢失，本地和異地備份起着至關重要的作用。
是以對于DBA來說，備份工具的使用、備份政策的選擇以及備份系統的完善都是需要時刻關注的，定期進行備份的有效性測試更是不能忽視的重要環節。
下面我從最基本的備份類型和方法入手，結合“移動雲”MySQL資料庫本地和異地備份與恢複機制，跟大家分享和探讨下DBA在生産環境需要掌握的基本備份技能。
備份有哪幾種類型和形式？
根據備份形式的不同，MySQL資料庫備份可以劃分為：
- 冷備份；
- 熱備份；
- 溫備份；
- 實體備份；
- 邏輯備份；
- 本地備份；
- 遠端備份；
- 全量和增量備份、日志備份。
1）其中，根據備份時資料庫的狀态可以分為冷備份、熱備份和溫備份
冷備份是指在資料庫關閉的情況下進行備份，這種備份非常簡單，隻需要關閉資料庫，複制相關的實體檔案即可。目前，線上資料庫一般很少能夠接受關閉資料庫，是以該方式很少使用。因為是直接拷貝資料檔案，冷備份的恢複無法解決資料空洞的問題，同時在跨平台進行恢複需要考慮系統版本、檔案大小寫敏感和浮點數格式等因素，通常在硬體故障下，如磁盤故障而且不能确認存儲的其他盤是否有問題，需要把資料目錄中的資料遷移到其他的實體裝置上。
熱備份是指在資料庫運作的過程中進行備份，對生産環境中的資料庫運作沒有任何影響。常見的熱備方案是利用mysqldump、xtrabackup等工具進行備份。熱備份也叫線上備份，大多數基于資料塊變化跟蹤備份，服務不需要停機，對業務影響小，通常生産環境的備份都是圍繞着線上備份展開。
溫備份也是在資料庫運作的過程中進行備份，但是備份會對資料庫操作有所影響。該備份利用鎖表的原理備份資料庫，由于影響了資料庫操作，故該備份方式也很少使用。
2）根據備份檔案的種類可以分為實體備份、邏輯備份
實體備份是指複制資料庫的實體檔案，實體備份是對實體檔案資料塊的拷貝，通過拷貝日志檔案和資料檔案，并在資料檔案應用日志進行checkpoint前滾、復原來達到資料備份的一緻性，相對于邏輯備份效率要快很多。
實體備份即可以在資料庫運作的情況下進行備份，也可以在資料庫關閉的情況下進行備份。該備份方式不僅備份速度快，而且恢複速度也快，但由于無法檢視備份後的内容，是以隻能等到恢複之後，才能校驗備份出來的資料是否正确。
邏輯備份是指備份檔案的内容是可讀的，通常是将資料導出為可執行可讀的SQL文本檔案，該文本一般是由一條條SQL語句或者表的實際資料組成，是SQL layer層得到的SQL語句。常見的邏輯備份方式有mysqldump、SELECT*INTO OUTFLE等方法。這類備份方法的好處是可以觀察備份後的檔案内容，缺點是恢複時間往往會很長，适用于資料量較小的執行個體。
日常運維工作中DBA實際使用的備份手段通常是邏輯備份和實體備份相結合，MySQL相關的邏輯備份工具主要有：
- MySQL官方的mysqldump，屬于單線程的邏輯備份工具；
- 開源的MySQL多線程邏輯導出工具mydumper，以行記錄級别實作并行備份，主線程切分chunk，并按chunk進行導出；
- 5.7版本推出的并行多線程邏輯備份工具mysqlpump，該工具多線程的顆粒度是表，單表依然是單線程導出；
- 通過SQL語句導出到文本。
從邏輯備份工具由單線程到多線程的演變特點可以看出，邏輯備份效率較低，遇到執行個體過大時，邏輯備份就不是一個好的選擇了，這時DBA通常考慮實體備份，MySQL常用的實體備份工具主要有：
- MySQL Enterprise Backup (企業版本)；
- XtraBackup。
以上工具都可以同時備份MyISAM和InnoDB存儲引擎表，可以了解為是對日志檔案和資料檔案的拷貝，“移動雲”生産環境主要采用XtraBackup工具進行資料庫的本地備份。
3）根據備份内容，可以劃分為全量備份、增量備份、日志備份
全量備份是指對資料庫進行一次完整的備份，備份所有的資料。這是一般常見的備份方式，可以使用全量備份快速恢複資料庫，或者搭建從庫。恢複速度也是最快的，但是每次備份會消耗較多的磁盤空間，并且備份時間較長。
增量備份是指基于上次全量備份或增量備份，對資料庫新增的修改進行備份。增量備份又分為累積增量備份和差異增量備份。增量備份依賴于最近一次的全量備份，恢複時同樣依賴于全量恢複和增量備份的應用，這種備份方式有利于減少備份時磁盤的使用，加快備份速度。但是恢複的時候速度較慢，并且操作也比較複雜。
日志備份是指對MySQL資料庫二進制日志的備份。該備份方式一般與上面的全量或增量備份結合使用，可以使資料庫恢複到任意位置，例如可以采用全量備份和Binlog備份來實作整體備份需求。
4）根據備份檔案存儲位置，可以劃分為本地備份、遠端備份
考慮到本地備份存儲資源的消耗以及選擇遠端備份能夠減少資料庫伺服器的記憶體和IO壓力，“移動雲”生産環境采用本地+遠端備份（NBU）的方式，本地由于磁盤空間限制僅保留近期的備份檔案，并保證能夠快速恢複，遠端則用于保留較長時間的曆史備份。
前面提到的多種備份方式，每個都有自己的優缺點。在“移動雲”生産環境中，備份一般需要滿足以下三個需求：
- 備份時，資料庫不能中斷服務，即需要熱備份；
- 生産環境中，需要随時恢複到某個時間點，便于線上出現問題後的資料復原；
- 可以用來快速搭建新的從庫，建立複制關系，實作資料的高可用、負載均衡等目标。
考慮到上述需求，我們選擇本地以實體備份為主，邏輯備份為輔，加上遠端備份，來滿足線上使用資料庫的需求。
備份原則：每周一次全備，每天一次增備，本地統一保留21天，對于超過21天的資料如無特殊需求，到後期會自動删除，對于較重要的資料需保留更久則通過遠端備份實作（NBU備份）。
備份方案：備份通過crontab進行排程，每天晚上2點進行備份。備份腳本統一放在各節點指定目錄下，如：/path/sh/backup.sh ，備份日志統一放在/path/logs/backuplog/目錄下。備份形式為實體備份。該備份為速度最快的模式，不會鎖表，對線上業務基本無影響。備份檔案過期後會自動删除，可以避免保留大量的備份資料導緻磁盤空間不足。
實體備份和恢複可以采用開源Percona XtraBackup工具。xtrabackup用于熱備innodb,xtradb表中的資料，不能備份其他類型的表，也不能備份資料表結構，innobackupex是對xtrabackup進行封裝，提供了更為全面和完善的功能，可線上備份innodb,myisam類型的表，恢複時需要停服務。innobackupex分為全量備份和增量備份。
全量備份
1）備份階段
在全量備份時，隻需要指定連接配接資料庫的參數和備份目錄即可。
innobackupex --defaults-file=/path/conf/my.cnf --host=127.0.0.1 --port=3306 --user=mysql --password=backup /path/backup_dir/ 在備份完成後，innobackupex會輸出以下資訊：
***
190827 17:36:04 innobackupex:Starting ibbackup with command:xtrabackup***
***
innobackupex: Backup created in directory '/path/backup_dir/20190827_165206_full'
innobackupex: MySQL binlog position: filename 'mysql-bin.032074', position 271, GTID of the last change '22513e1b-6b32-11e6-839c-6c92bf2a2c87:1-2004,
7b405c05-b3a1-11e5-8c14-fa163eb8d0f8:1-16,
85977e48-4c5e-ee1a-54ce-d90c0a6017b4:1-5828461614'
innobackupex: Backup history record uuid 1da6bda3-c8ae-11e9-9e2c-6c92bf2a2c07 successfully written
190827 17:36:16 innobackupex: Connection to database server closed
190827 17:36:16 innobackupex: completed OK!
2019-08-27 17:36:16 backup complete!.
2019-08-27 17:36:16 backup success! 通過輸出資訊可以看出，其實innobackupex在執行時，調用了xtrabackup腳本。并且備份檔案會存儲在一個以備份時間命名的子目錄下。
2）Prepare階段
在建立備份後，備份資料通常處于不可用狀态。因為在redo log中可能存在未送出的事務，需要通過準備階段來使備份資料達到一緻的狀态。通過prepare階段，備份資料就可以用來恢複了。
在準備階段，需要指定--apply-log選項和備份路徑。
innobackupex --defaults-file=/path/conf/my.cnf --apply-log /path/backup_dir/2019-08-27_17-36-16 執行後輸出資訊如下：
InnoDB:Shutdown completed;log sequence number 1735134
190827 17:44:33 innobackupex:completed OK! 狀态顯示為“completed OK”,表明innobackupex執行完了所有所需的操作，資料達到一緻狀态。
3）恢複階段
在Prepare階段過後，如果需要用備份資料來恢複資料庫，則隻需要指定--copy-back和備份資料所在的目錄即可，此時資料庫需處于關閉的狀态。
innobackupex --defaults-file=/path/conf/my.cnf --copy-back /path/backup_dir/2019-08-27_17-36-16 innobackupex将所有的資料檔案複制到datadir目錄，該目錄由my.cnf配置檔案中datadir參數指定。最後輸出如下資訊：
innobackupex:Finish copying back files.
190827 17:50:33 innobackupex:completed OK! 複制完成後，檔案屬性不會改變，是以建議将datadir和backup_dir目錄權限設定為相同，否則在啟動MySQL資料庫之前，需修改檔案的所有權。
chown -R mysql:mysql /path/datadir 另外，在恢複過程中，datadir目錄必須為空，如果不為空，innobackupex --copy-back 将不會複制，除非指定了 --force-non-empty-directories選項。
增量備份
在日常的資料庫備份中，并不是每次備份之間的資料都有所改變。DBA可以隻備份那些修改的部分。不僅可以節約備份所需的磁盤空間，也可以大大縮短備份的時間。增量備份即可以做到這一點，因為在InnDB頁面中有一個日志序列号（LSN），它充當資料庫版本号的作用。每次修改資料庫，這個數字就會增加。增量備份複制指定LSN位置以後的所有頁面。
1）備份階段
增量備份基于全量備份，是以首先需要建立一個全量備份，這時備份目錄中會存在xtrabackup-checkpoints檔案，内容如下：
backup_type = full-backuped
from_lsn = 0
to_lsn = 834506398072
last_lsn = 834632595548
compact = 0 
增量備份時需要指定--incremental選項和basedir資訊。
innobackupex --defaults-file=/path/conf/my.cnf --host=127.0.0.1 --port=3306 --user=mysql --password=backup --incremental --incremental-basedir=/path/backup_dir/ /path/incremental_backup_dir 增量備份完成後，會在新建立的增量備份目錄中/path/incremental_backup_dir建立一個時間目錄，例如:/path/incremental_backup_dir/2019-8-27_17-48-30。同樣在該目錄中存在xtrabackup-checkpoints檔案内容如下：
backup_type = incremental
from_lsn = 834506398072
to_lsn = 838872449882
last_lsn = 838890942246
compact = 0 增量備份還可以基于以前的增量備份完成。
innobackupex --defaults-file=/path/conf/my.cnf --host=127.0.0.1 --port=3306 --user=mysql --password=backup --incremental --incremental-basedir=/path/backup_dir/ /path/incremental_backup_dir/ xtrabackup-checkpoints檔案内容如下：
backup_type = incremental
from_lsn = 838872449882
to_lsn = 843244982934
last_lsn = 843341702758
compact = 0 前面提到增量備份是基于LSN的，是以增量備份也可以直接指定LSN來完成，例如：
innobackupex --defaults-file=/path/conf/my.cnf --host=127.0.0.1 --port=3306 --user=mysql --password=backup --incremental --incremental-lsn=834506398072 /path/incremental_backup_dir/ 2）Prepare階段
在增量備份的prepare階段，所有已送出的事務必須在每個備份上重放，這将完全合并到增量備份。為了得到可用的備份，未送出的事務必須復原。如果已經在全量備份上重放了送出的事務并復原了未送出事務，則将無法在此備份上添加增量。如果在增量備份上執行上述操作，則将無法添加其餘的增量備份。是以prepare階段需要制定--redo-only選項，例如：
- 首先，在全量備份上執行innobackup --apply-log --redo-only base_dir
- 然後，在所有的增量備份上（除最後一個）執行innobackup --apply-log --redo-only --incremental-dir=/path/incremental_backup_dir base_dir
- 在最後一個增量備份上執行innobackup --apply-log --incremental-dir=/path/incremetal_backup_dir base_dir
3）恢複階段
通過prepare階段，base目錄包含了所有資料，在恢複時，隻需要通過以下操作即可：
innobackupex --defaults-file=/path/conf/my.cnf --copy-back /path/base_dir 遠端備份
在現網環境中，由于本地磁盤空間有限，通常本地僅保留一個月左右的備份資料，對于更早的資料如無特殊需求，到後期會自動删除，對于較重要的資料需保留更久則通過遠端備份實作（Netbackup備份）。
不過在遠端備份時，備份傳輸引發的網卡流量以及對線上業務造成影響不可忽視，需要考慮到網卡的能力，不能因為備份影響了線上業務的運作。這時可以考慮使用雙網卡，一塊用于備份，一塊用來提供線上服務。如果沒有這個條件，可以考慮在備份時限制速度來達到目的。
1）遠端限速流備份
這種備份方式最大的好處是不消耗本地磁盤空間，并且通過該備份方式備份完成後，資料庫的最後位置（binlog位點）就是最新的，因為傳輸完成的時候，備份才結束。相對别的備份方式，該備份方式的binlog位點資訊更新。
當需要将DB主機的資料備份到遠端伺服器上，在遠端伺服器上開啟一個端口利用pv和nc達到限速的目的，例如：
mkdir -p /tmp/backup
nc -l port | pv -q -L 100m | tar -xi 然後在DB主機上執行備份，如下：
mkdir -p /tmp/tmpbackup
innobackupex --defaults-file=/path/conf/my.cnf --host=127.0.0.1 --port=3306 --user=mysql --password=backup --stream=tar --tmpdir=/tmp/tmpbackup --salve-info /tmp/backup /path/backup (路徑與遠端伺服器上nc的目前路徑一緻)
也可以将備份集打個tar包，如下：
innobackupex --defaults-file=/path/conf/my.cnf --host=127.0.0.1 --port=3306 --user=mysql --password=backup --stream=tar --tmpdir=/tmp/tmpbackup --salve-info /tmp/backup /path/backup 2>/path/backup/bak_tar.log | gzip 1>/path/backup/test.tar.gz 檢視bak_tar.log有無錯誤資訊，若顯示備份正常，則進入/path/backup/ 下執行tar -xvifz test.tar.gz. 檢視目錄大小（du -sh），并檢視備份檔案是否完整。
限速也可以通過innobackupex本地提供的參數--throttle通過限制磁盤的I/O來實作，一定程度上減少磁盤壓力。不過它僅限于InnoDB的日志和檔案的操作，對其他的存儲引擎沒有效果。
遠端限速流備份的也存在一定的缺點，比如傳輸過程中，如果網絡出現問題，那麼備份将會失敗，并且由于限速，導緻備份時間拖長。
2）Netbackup遠端備份
NetBackup是“移動雲”備份與恢複管理工具。在備份過程中，通過網絡将資料傳送至NetBackup伺服器，該伺服器則通過使用相關政策為其選擇最合适的存儲媒體類型。
在恢複過程中，管理者能夠浏覽到使用者需要恢複的資料和目錄，同時，NetBackup伺服器會找到這些資料或目錄并且幫助客戶進行恢複，執行過程可以選擇：建立備份作業排程和時間視窗、建立特定日期備份作業排程和建立特定日期不激活備份作業排程。系統架構如下圖所示：
常見問題
前面介紹了備份恢複相關基礎知識，我們知道日常運維中較常用的備份工具是mysqldump、Percona Xtrabackup，大多數DBA的備份恢複自動化體系和平台都是圍繞這兩個工具進行開展。
那面對成百上千個MySQL執行個體的維護，備份恢複有哪些問題呢？下面我們具體來看一下。
1）本地存儲備份，磁盤空間需求更大，占用資料庫伺服器主機闆系統總線，記憶體，CPU，硬碟IO資源，不僅造成資源的浪費而且由于資源消耗放大了備份對線上業務的影響。
2）集中化管理缺失，備份的方式多樣化，恢複演練錯誤率高，維護困難。
3）備份檔案有效性校驗，備份檔案不做校驗通常是最容易忽視的問題，出現故障時發現備份檔案不可用會造成嚴重損失。
4）叢集備份節點選擇問題。備份或多或少對線上業務都有影響，建議備份任務在slave、statistic或隻讀節點上執行， 那麼當叢集發生主備切換，如果備份節點沒有動态進行切換，導緻在寫庫上進行備份，使線上業務受備份操作影響。
早期我們通過Netbackup實作異地備份，進而減少本地磁盤空間的消耗，并通過編寫自動化腳本，引入一些開源工具，如：zabbix用于監控備份執行情況，ELK工具用于備份日志的記錄和查詢，ansible用于腳本的批量推送和維護。
并搭建備份恢複測試環境來實作備份有效性校驗，例如可以通過下面簡單的方式進行日常備份和集中恢複測試：
但總體而言備份體系中依然缺乏集中化管理，如份政策的修改和備份腳本的維護較複雜，備份完成情況、占用空間大小、完成時間以及校驗結果等内容的記錄和呈現也不夠直覺，缺少圖形化界面。
腳本存放在資料庫本地缺乏版本維護和統一管理，突發故障或變更前的臨時備份依然靠手工ssh登入資料庫主機執行，存在效率低和安全性差的問題。是以在這樣的背景下，我們也開始尋求更高階的運維方式——平台化 。
平台化的目标是整合已有的備份工具和手段，将複雜操作、重複操作程式化，并收口登入資料庫主機的操作行為，提高操作安全性，增加管理和稽核機制，提升運維效率，減少人為故障，解放運維人員。
備份管理平台
平台建構采用前、後端分離的方式，保證一定的擴充性并盡量避免耦合。因為平台不僅面向DBA還要面向系統運維人員，是以要使用動态菜單。不同權限，不同專業的人看到的菜單是不同的。
平台可以記錄記錄檔，具備安全審計的能力。在互動實作方面，要做到可視化、自動化和自助化。平台開發後端采用的是Django架構，前端采用Vue.JS，同時利用了緩存Redis和MySQL作為資料存儲，通過标準的restful接口進行資料傳輸。
Redis作為資訊緩存器，主要存儲一些前端Dashboard以及資料庫的基本資訊，加快前端通路速度。
Django-Celery子產品用于異步任務，由于備份操作執行的時間較長，沒有辦法立即傳回結果，是以需要采用異步形式完成操作。
Ansible用于批量的備份執行、校驗以及備份政策的修改。資料連接配接采用pymysql子產品，能夠實作不同種類資料庫連接配接。
備份管理功能上主要包括：備份執行、備份恢複、曆史備份和備份政策，備份監控放在了首頁上進行展示，頁上可以看到備份的執行時間、執行情況、備份校驗和備份檔案大小等資訊，部分内容如下圖所示：
clipboard.png
管理平台可以提供備份執行和備份恢複的功能，除了日常備份與恢複測試，這裡可以提供變更前或故障發生時的臨時備份，如下：
備份執行
備份恢複時可以指定某個時間點的備份檔案對現網資料進行恢複。平台也提供了在測試環境進行資料恢複的接口，可以将個别業務表的曆史資料恢複并導出，用于資料比對和故障排查。
備份恢複
可以通過管理平台對備份政策進行設定，對日常備份的執行時間、保留周期、備份方式等進行設定或修改，并且提供了對每套資料庫進行政策修改的接口。
備份政策修改
容災
容災是在備份的基礎上，建立一個異地的資料系統，該系統是本地關鍵應用資料的一個實時複制。
容災方案應支援自動災備切換和手工災備切換功能。在災難發生時，支援進行自動檢測和切換，啟動異地高可用的裝置或節點，切換後資料隻讀類服務應可即時可用，保障業務連續性。部分複雜業務功能可進行手工災備切換。同時，營運管理平台應該提供手工災備切換功能，允許維護人員手工切換主、備裝置或節點，以進行系統維護或者災備演練。
為實作容災，移動雲營運管理平台及後端資料庫以異地（華南、華北兩個區域）主備方式部署和運作，業務資料實作異地異步同步。華南2資源池内部署營運管理平台的主服務節點，華北1資源池内部署備節點。當華南2資源池整體故障時，可啟用華北1備節點的營運管理平台服務。
RPO／RTO測算
進行災備解決方案設計時，需關注災備的兩個關鍵技術名額：
1）RTO：RecoveryTime Object，恢複時間目标。指災難發生後，從IT系統當機導緻業務停頓之刻開始，到IT系統恢複至可以支援各部門運作，業務恢複營運之時，此兩點之間的時間段稱為RTO。RTO是反映業務恢複及時性的名額，展現了企業能容忍的IT系統最長恢複時間。RTO值越小，代表容災系統的恢複能力越強，但企業投資也越高。
2）RPO：Recovery Point Object，恢複點目标。指災難發生後，容災系統進行資料恢複，恢複得來的資料所對應的時間點稱為RPO。RPO是反映資料丢失量的名額，展現了企業能容忍的最大資料丢失量的名額。RPO值越小，代表企業資料丢失越少，企業損失越小。
根據資料類型和資料保留周期測算推導自己的RPO／RTO。
- 基于資料重要級别分析，為各系統進行分級為A、B、C、D；
- 基于保留周期分析，定義各備份資料的保留時間；
- 基于資料類型分析，區分資料庫、應用資料、配置檔案系統等。
根據以上調研可以進行RPO和RTO的測算，例如：
資料庫災備方案
資料庫用于存放營運管理平台所有使用者的持久化業務資料。為保證切換至備節點後，使用者業務資料無丢失，需實作資料庫異地災備。
資料庫災備包括了災難發生前資料的實時異地備份及故障排除後的資料恢複方法。
1）資料庫備份
假設節點1為主節點、節點2為災備。在節點2建立節點1資料庫副本，包括資料庫以及消息隊列等中間件持久化資料。目前副本隻支援單節點形式部署，不支援負載均衡模式，節點1資料庫中的增量資料每秒進行一次異地備份，存放到節點2災備資料庫中。節點1和節點2間使用專線傳輸，保證資料備份的及時可靠。當故障發生時，對于資料庫切換過程中暫存于節點1資料庫中的資料可能會丢失，如訂單狀态，支付狀态等，需要在完成資料庫切換後由使用者重新操作。
2）資料庫恢複
災備中心切換成功後，使用者資料将存放于節點2的災備資料庫中。故障排除後，需要将資料恢複到節點1。從節點2災備資料庫啟用至故障恢複期間産生的訂單、使用者資料需要以全量複制形式恢複到節點1資料庫，該過程使用手動進行。資料恢複後再将資料庫通路入口從節點2調整到節點1。至此完成資料庫的恢複操作。
3）同步方案
小結
結合以上備份和容災方案就建構了移動雲一套完整的資料庫災備體系，為企業使用者提供多資料中心帶來的更進階别的安全性和産品的穩定性以及實作更細産品顆粒度級别的備份控制。
>>>>活動推薦
10月26日，北京：dbaplus社群将舉辦資料架構與優化沙龍，攜手京東、AWS、滴滴、新炬網絡、愛可生等資料領域資深技術專家，聚焦資料中台、資料架構與優化的熱門話題。碼上了解更多詳情↓