【AWS徵文】帶你輕鬆遷移數據庫到 AWS

現在,企業上雲離不開數據庫上雲。然而,雲上有不少數據庫類型,企業該如何選擇?將數據庫遷移到雲端,該有哪些步驟呢?不一樣的業務場景下,企業該如何選擇?本文將介紹 AWS 各類經常使用數據庫特性,以及如何知足客戶不一樣業務需求,並列舉數據庫遷移案例爲你們演示如何輕鬆便捷的把數據庫遷移上雲。html

1、AWS 數據庫概覽

在這個互聯網極其發達的時代,咱們每一個人會接收以及生產各式各樣的信息,數據的重要性已經***到每一個角落,成爲每一個行業發展和變革的必要元素。咱們平常使用的手機應用,好比微信、支付寶、微博等,裏面的數據都是須要數據庫來進行存儲,不一樣的應用會使用不一樣類別的數據庫,甚至同一個應用可能同時使用多種數據庫。mysql

應用離開了數據庫就像魚兒離開了水,因而可知數據庫在當今互聯網的重要性。咱們甚至能夠說當今世界最寶貴的資源再也不是石油,而是數據。隨着業務的快速發展,全球化業務新興需求增長,本地傳統數據庫已經沒法爲快速發展的業務提供支持,咱們須要探索一種新的方式,把本地數據庫遷移到雲中,利用雲中數據庫的優點來解決本地數據庫中遇到的瓶頸問題。sql

我對各家雲廠商數據庫種類作了一個比較,發現 AWS 爲用戶提供的數據庫種類最爲豐富,幾乎把全部數據庫相關的應用場景都捕捉到了。下面經過一個列表,來瀏覽一下 AWS 的數據庫種類,其中關係型數據庫最爲豐富,也是目前應用使用最多的數據庫。數據庫

image-20200807102743011

以上這些數據庫由 AWS 徹底託管,用戶不用去管理底層硬件系統升級維護等相關工做,這也是推薦使用全託管數據庫而非自建數據庫的緣由。爲了方便客戶數據庫遷移上雲,AWS 還爲客戶提供了很是方便的遷移工具 DMS,幫助用戶輕鬆經濟高效的完成遷移任務。緩存

那麼面對這麼多種類的數據庫,尤爲是一些新型數據庫,咱們歷來沒有使用過,咱們該如何選擇?咱們須要從業務場景爲出發點來分析使用哪一種數據庫,下面我對 AWS 數據庫的使用場景作個簡單的介紹,也讓你們對 AWS 各類數據庫的應用場景有一個大體瞭解。安全

數據庫種類 應用場景
關係數據(RDS) 傳統應用程序、ERP、CRM 、電子商務
鍵值數據(DynamoDB) 高流量 Web 應用、電子商務系統、遊戲應用程序、微服務
寬列數據(Keyspaces) 用於設備維護、隊列管理和路線優化的大規模工業應用程序
文檔數據(DocumentDB) 內容管理、目錄、用戶配置文件、移動和 Web 應用程序
內存數據(ElasticCache) 緩存、會話管理、遊戲排行榜、地理空間應用程序
圖數據(Neptune) 欺詐檢測、社交網絡、推薦引擎、知識圖譜
時序數據(Timestream) IoT 應用、開發運營和工業遙測
分類帳數據(QLDB) 系統記錄、供應鏈、註冊、銀行事務

初步瞭解 AWS 各項數據庫的應用場景以後,咱們詳細介紹 AWS 各項數據庫特性,以及 AWS 數據庫如何知足用戶在各類業務場景下面的需求。服務器

數據庫家族

關係型數據庫

關係型數據庫是起源很是早的數據庫,也是目前各類應用使用最多的數據庫。咱們使用各類應用都須要註冊用戶,這些用戶數據存放在關係型數據庫裏面;你在電商網站下了一個訂單,訂單也是存放在關係型數據庫裏面;咱們訪問的網站,其後臺數據也是存放在關係型數據庫裏面。因此說關係型數據庫無所不在。微信

說到 AWS 的關係型數據庫,那不得不說一下 Amazon Aurora,Aurora 是 AWS 專爲雲而打造的雲原生數據庫,它兼容 MySQL 和 PostgreSQL,它能夠支撐咱們各類關係型數據庫的應用場景,性能好、易擴展、安全、便於管理,Aurora 如此好用,也依託於它下面的一些特性:網絡

  • 性價比:吞吐量爲標準 MySQL 的五倍,標準 PostgreSQL 的三倍,成本只有商業數據庫的十分之一。
  • 擴展性:基於共享存儲,主從複製延遲很低,可跨三個可用區擴展至最多 15 個只讀副本。
  • 可用性與持久性:具備容錯能力的自我修復存儲;跨三個可用區創建六個數據副本;持續備份至 S3。
  • 安全性:VPC 網絡隔離、靜態/傳輸數據加密、知足大多數地區合規性要求。
  • 全球數據庫:數據庫跨越多個 AWS 地區同步複製,將數據庫置於用戶端,能夠實現低延遲(典型延遲小於 1 秒)的本地讀取和跨區域災難恢復。
  • 無服務器:能夠根據工做負載自動擴容縮容,無需關心底層硬件擴展,適合業務波動的應用。

Aurora 具備不少傳統數據庫不具備的特性,這樣讓 Aurora 成爲關係型數據庫的首選。不過若是你不想更換數據庫類型,把本地現有的數據庫遷移到雲中,AWS 還爲用戶提供 MySQL、MariaDB、PostgreSQL、SQL Server、Oracle 等關係型數據庫,客戶可選擇相同的數據庫引擎進行遷移。而且這些數據庫依託於 AWS 強大的基礎設施和管理,一樣安全穩定。架構

若是 Aurora 很是吸引你,而你如今用的是 SQL Server 或者 Oracle,那該怎麼辦?不用擔憂,AWS 爲客戶提供了 Schema Conversion Tool、DMS 這兩個服務,能夠幫助客戶評估而且轉換數據庫對象,很是便捷地將本地數據庫遷移到 Aurora。

鍵值數據庫

互聯網發展到今天,數據表愈來愈大,有的應用要求寫得快、讀的快等需求。關係型數據庫已經沒法知足咱們的需求,所以 NoSQL 數據庫也就誕生了。咱們把一些不須要關係查詢,要求讀寫快的應用數據放置在 NoSQL 數據庫裏面來解決性能問題。

考慮到客戶的需求,AWS 也爲客戶提供了自研的 NoSQL 數據庫 Amazon DynamoDB,它支持鍵值存儲,也支持文檔存儲,特別以鍵值存儲爲核心,面對海量數據,性能很是強悍。因其由 AWS 徹底託管,因此也是無服務器架構中的重要一員。

  • 擴展性:可自動縱向擴展和縮減表,以針對容量作出調整並保持性能,提供任意級別的請求流量。

  • 高性能:對於通常的請求,DynamoDB 在個位數毫秒內能夠完成,並且處理請求的速度不會隨着數據量的增長而減慢。
  • 分佈式:無中心化架構,一個表上的數據能夠分佈到幾百臺機器上。

我也在 AWS 官方渠道瞭解到,匯量科技是一家廣告公司,他們也大量使用了 AWS 的服務,尤爲是對廣告點擊的數據,正是採用了 DynamoDB 數據存儲,能夠支撐 2019 年日均廣告請求量 600 億次,峯值高達 1000 億次。如此巨大的請求量,放在關係型數據庫將沒法支撐,因而可知 DynamoDB 在這種應用場景性能多麼強悍。

文檔數據庫

JSON 數據無數不在,它是一種很是靈活的格式,你能夠很方便地修改一條數據的 Schema。它是一種輕量級的數據交換格式,目前使用最普遍的 API 標準 RESTfull API,它的輸出標準也是 JSON。使用 JSON 進行數據建模最符合人類語言的邏輯。以上這些使用場景,咱們都須要一種文檔數據庫來存儲 JSON 數據,它既不是關係型數據庫,也不是鍵值數據庫。

哪些應用場景會用到文檔數據庫呢?由於 JSON 數據的靈活,文檔數據已經***到各個領域,好比在遊戲中,存儲用戶信息,裝備積分等;在物流中,存儲訂單信息,訂單狀態;在社交中,存儲用戶信息以及用戶發表的朋友圈信息;在視頻直播中,存儲用戶信息和禮物信息等。

爲了知足客戶這些使用場景,AWS 爲客戶提供了 DocumentDB 數據庫,見名知意,它是一個雲原生的文檔數據庫,與 MongoDB 兼容,你能夠把現有的 MongoDB 數據庫經過 DMS 或 mongodump/mongorestore 等原生方式遷移上 AWS。

DocumentDB 擴展性很強,水平擴展在分鐘級別,最多能夠擴展到 15 個讀副本;垂直擴展也在分鐘級,最高擴展至 768 GiB 內存;存儲能夠自動擴展,最高支持 64TB。這些特性都是咱們在自建數據庫很難實現的。

內存數據庫

現在的應用越作越大,不少都已經開始進行分佈式或者微服務架構,這時候就須要一個存儲庫來儲存用戶的會話信息,否則用戶可能處於頻繁的登錄狀態;還有應用要求提高數據查詢速度,這就須要給數據庫添加緩存層等。以上這些應用場景都會須要內存數據庫。

那麼 AWS 一樣在雲中爲客戶提供了徹底託管的內存數據庫 Amazon ElastiCache,客戶能夠把一些熱數據、會話數據、消息數據、排行數據等存放在其中,以加速數據的存取速度。它支持兩種存儲引擎,Memcached 和 Redis。

  • 極致性能:可以支持要求最嚴苛且須要亞毫秒級響應時間的應用程序。
  • 輕鬆擴展:經過使用 AWS 管理控制檯或者簡單的 API,用戶能夠根據應用須要添加或刪除緩存集羣中的節點。
  • 安全性:支持 Amazon VPC,能夠進行網絡隔離。經過安全組來管理集羣的訪問權限。
  • 高可用:可將 2 到 6 個節點納入一個具備副本的集羣,若是一個節點出於任何緣由發生故障,您不會丟失全部數據。

圖數據庫

關係型數據庫有了,鍵值和內存數據庫也有了,已經基本知足大部分應用的平常需求,對於 AWS 來講,這還不夠。用戶還會面臨性能和 schema 變動不易的問題,所以 AWS 推出了圖數據庫 Neptune。

使用圖形數據庫處理社交網絡數據很是高效,Amazon Neptune 能夠快速輕鬆地處理大量的用戶配置文件和交互,從而構建社交網絡應用程序。

時序數據庫

顧名思義,時序數據庫是和時間相關的數據庫。由於不少對數據的查新都是以時間段爲基礎的, 適用於 IoT 和運營應用程序。所以 AWS 爲用戶提供了 Amazon Timestream,專門處理時序數據,目前還處於註冊預覽版。

分類帳數據庫

分類帳數據庫的使用場景也很好理解,最適合的場景是「記帳本」。「帳本」是不能被更改的,每一筆記錄都不能被改動,被忠實的記錄下來,以備查詢。Amazon Quantum Ledger Database 就應運而生了。

這聽起來和「區塊鏈」有點關係,不過 QLDB 是有中心的,而「區塊鏈」是去中心化的,那麼你可能會問,AWS 有沒有去中心化的數據庫,回答是有的,那就是 Amazon Managed Blockchain。咱們很難去想 AWS 到底不存在什麼數據庫,用戶須要的它有,用戶用不到的它也有,能夠說達到了「應有盡有」的程度。

遷移工具

介紹了這麼多的數據庫,以及各類數據庫的使用場景和特性,幾乎知足平常應用的全部需求,那咱們確定是想知道如何使用這些數據庫,以及如何把目前本地自建的數據庫遷移到雲中。下面咱們將介紹 AWS 爲客戶提供的遷移神器 AWS Database Migration Service,以及 DMS 如何幫助客戶便捷高效地把數據遷移到雲中的數據庫。

一樣 DMS 也是徹底託管的,這讓咱們把主要精力放在遷移任務上面來。DMS 支持多種數據庫做爲遷移的源,也支持多種數據庫做爲遷移的目標,從下面的表格能夠詳細瞭解支持哪些數據庫:

數據遷移的源 數據遷移的目標
Oracle、SQL Server、MySQL、MariaDB、PostgreSQL、SAP ASE、MongoDB、DB2 LUW、Azure SQL、Amazon RDS、S3 Oracle、SQL Server、MySQL、MariaDB、PostgreSQL、SAP ASE、Amazon RDS、Amazon Redshift、Amazon S三、Amazon DynamoDB、Amazon Elasticsearch Service、Amazon Kinesis Data Streams、Amazon DocumentDB、Amazon Neptune、Apache Kafka

咱們能夠從表格中看到各類數據庫引擎,AWS DMS 支持同構數據庫遷移,如 MySQL 遷移到 MySQL,也支持異構數據遷移,如 Oracle 到 MySQL,在進行異構數據庫遷移的過程,AWS 還爲用戶提供一款工具 AWS Schema Conversion Tool,可使用 AWS SCT 將源數據庫架構和大部分對象自動轉換爲與目標數據庫兼容的格式。

對 DMS 的總結,能夠簡單歸納爲下面幾個小特性:

  • 簡單易用
  • 最少停機時間
  • 持續數據複製
  • 多數據源支持
  • 運行可靠

AWS DMS 能夠成爲複製和遷移數據庫的最佳工具,它能夠幫助用戶將數據庫工做負載遷移到 AWS 並更改數據庫引擎,同時最大程度地減小停機時間。根據 AWS 的說明,使用 AWS DMS 已經進行了 20,000 個數據庫到 AWS 雲的遷移。因爲使用該產品得到了如此普遍的成功,所以沒有理由不將數據庫遷移到 AWS,那麼下面就開始咱們的數據庫遷移之旅吧。

遷移方式

全部的數據庫都有本身的備份還原工具,使用這些工具咱們能夠方便的進行數據離線遷移,可是會形成較長的停機時間,主要看數據量的大小。若是須要最小的停機時間,那 DMS 是最佳選擇。下面大體列舉了各類遷移方式對業務的一個影響程度,能夠根據本身的實際狀況進行選擇。

因素 離線(轉儲) 混合 在線(DMS)
複雜度 很是簡單 複雜 中等
速度 中等
停機時間

2、雲上數據庫遷移實踐

遷移解決方案

咱們在本地數據中心有各式各樣的自建數據庫,若是對數據庫遷移上雲,咱們該如何選擇雲中的數據庫呢,我下面簡單整理了一個列表,針對不一樣的場景,咱們能夠選擇對應的解決方案。

  • 現有應用程序
    • MySQL ---> Amazon Aurora for MySQL,RDS for MySQL
    • PostgreSQL ---> Amazon Aurora for PostgreSQL,RDS for PostgreSQL
    • MariaDB ---> Amazon Aurora for MySQL,RDS for MariaDB
    • Oracle ---> 利用 AWS SCT 檢測複雜性因素 ---> Amazon Aurora,RDS for Oracle
    • SQL Server ---> 利用 AWS SCT 檢測複雜性因素 ---> Amazon Aurora,RDS for SQL Server
    • MongoDB ---> DocumentDB
  • 新的應用程序
    • 若是不須要關係類功能 ---> Amazon DynamoDB
    • 若是須要關係類功能 ---> Amazon Aurora
  • 內存存儲/緩存

    • Redis ---> Amazon ElasticCache
    • Memcached ---> Amazon ElasticCache
  • 時序數據
    • Amazon Timestream(註冊預覽版)
  • 跟蹤各應用程序變動、加密可驗證性,具有中央可信權威
    • Amazon Quantum Ledger Database

遷移須知

數據庫是任何應用程序的主要組件之一,所以咱們必須謹慎地進行遷移。您須要知道數據庫的大小,數據庫內部表的大小以及數據庫模式。

使用 AWS DMS 將數據遷移到 AWS 很簡單。首先在 AWS 環境中建立複製實例,而後 AWS DMS 鏈接源數據庫端點和目標數據庫端點。遷移開始時,AWS DMS 會建立表,加載數據並同步數據庫。整個複製任務都由複製實例承擔,建議建立配置比較大的複製實例。

使用 AWS DMS 執行遷移的整體流程以下:

  1. 建立目標數據庫。
  2. 複製架構。
  3. 建立 AWS DMS 複製實例。
  4. 定義源數據庫和目標數據庫的終端節點。
  5. 建立並執行遷移任務。

將 MySQL 數據遷移到 Aurora MySQL

這個案例是一個同構數據庫遷移,相對來講比較簡單,遷移的方案有三種,能夠直接使用mysqldump導出數據,而後再導入到 Aurora,適合數據量不大的數據庫,另一種是直接把數據庫的源文件複製到 S3 存儲桶,可使用 Xtrabackup 備份數據庫而後傳到 S3 中,而後用這些文件還原到 Aurora 數據庫,適合比較大量的數據,不過這兩種數據庫都是離線傳輸,須要停機遷移。

針對實時在線遷移數據庫,咱們須要用到 AWS DMS,下面我將演示如何從一臺 MySQL 數據庫,實時遷移數據到 Aurora,對於源數據庫,咱們可使用 AWS RDS,或者在 EC2 上面的自建數據庫,或是其餘雲廠商的 MySQL 數據庫,下面我選擇使用在 EC2 上面自建的數據來進行演示,因此操做均在 AWS us-east-1 區域。

一、配置源數據庫

源數據庫咱們已經有了,你能夠建立一個只讀權限的臨時帳戶用於數據遷移,咱們這裏就直接用具備讀寫權限的帳戶演示。

二、建立 Aurora 數據庫

首先咱們在 AWS 控制檯中建立一個 Aurora MySQL 數據庫做爲咱們的目標數據庫,由於不是主要介紹建立數據庫,因此建立過程這裏再也不演示,建立完成以後,須要記錄下數據庫地址,帳戶密碼,固然爲了安全,你也能夠單首創建一個用於遷移的臨時帳戶。

image-20200723105014748

三、建立複製實例

AWS DMS 複製實例執行源和目標之間的實際數據遷移。複製實例負責整個數據的遷移,對更改的數據進行緩存,因此說大一點的實例性能更好,縮短遷移時間。打開 AWS DMS 控制檯,選擇建立複製實例,注意網絡方面的限制,須要複製實例能夠鏈接到兩個數據庫。

image-20200723110343964

四、建立 MySQL 終端節點

在 AWS DMS 控制檯中,在導航窗格中選擇 Endpoints (終端節點)。

image-20200723122719849

五、建立 Aurora 終端節點

目標終端節點會更簡單一寫,由於是 AWS RDS,咱們能夠直接勾選。

image-20200723122957328

六、建立遷移任務

遷移任務中的遷移類型咱們選擇複製現有數據以及持續複製變動的數據,記得源數據庫開啓 binlog 日誌。

在表映射選項裏面,選擇告知 DMS 應該遷移哪些表,遷移過程當中還能夠對錶名進行一些轉換,咱們這裏就選擇徹底複製整個數據庫。

image-20200723145434027

七、監控遷移任務

再等待一段時間以後,咱們能夠在任務詳情裏面看到數據遷移完成,而且目標數據庫數據檢查沒有問題。

image-20200723145510328

咱們能夠看到,經過 DMS 僅僅須要簡單幾步就能夠把數據庫遷移到 AWS,而且源數據庫變動數據會實時的更新到目標數據庫中。

將 SQL Server 數據庫遷移到 Aurora MySQL

這個案例是一個異構數據庫遷移,咱們會用到 AWS SCT 進行 Schema 轉換,AWS DMS 支持從 RDS 遷移到 RDS,因此此次的源數據庫 SQL Server 是 AWS RDS for SQL Server(Enterprise Edition)。

Schema 轉換

一、在本地計算機安裝 AWS SCT

須要在本身的電腦上面安裝 AWS SCT 工具,以及鏈接 SQL Server 的 JDBC 驅動和 Aurora MySQL 的 JDBC 驅動。

驅動下載地址參照官方文檔 https://docs.aws.amazon.com/zh_cn/SchemaConversionTool/latest/userguide/CHAP_Installing.html#CHAP_Installing.JDBCDrivers

而後啓動 SCT,配置一下剛剛下載的 JDBC 驅動。

image-20200723182444098

二、建立遷移項目

打開 AWS SCT,選擇建立一個新項目,選擇源和目標數據引擎。

image-20200723182928923

分別鏈接 SQL Server 和 AWS Aurora 數據庫。

image-20200723183730029

勾選咱們要遷移的數據庫,右鍵選擇 Create report。

image-20200723184142868

查看報告,看看有沒有問題,若是沒有問題,咱們就能夠直接進行轉換了。

image-20200723184429580

我這邊遇到一個存儲過程 MySQL 不支持,我這邊忽略掉,比較懂數據庫的人員能夠進行修正。

image-20200723185327872

三、Schema 轉換

問題處理掉以後,咱們就能夠進行 Schema 轉換了,和前面同樣,右鍵數據庫,選擇 Convert schema。

image-20200723185539813

執行以後,很快咱們在目標數據庫看到了轉換的 Schema。

image-20200723185824306

數據遷移

對於 SQL Server 的數據遷移方式,咱們選擇一次性遷移,不進行持續複製,持續複製配置過程稍微複雜一些,須要對源數據庫進行一些配置,須要持續複製的用戶,能夠參照 AWS 官方文檔配置。

一、建立複製實例

打開 DMS 控制檯,建立複製實例,一樣注意網絡狀況,複製實例須要連接源和目標數據庫。

image-20200723191210364

二、建立 AWS DMS 源和目標終端節點

建立完終端節點以後,首先運行一下測試,能夠鏈接成功便可。

image-20200723191737150

image-20200723191803996

三、建立遷移任務

能夠按照我下面的表格選擇來配置遷移任務。

Parameter Value
Task identifier AuroraMigrationTask
Replication instance replication-server
Source database endpoint sqlserver
Target database endpoint dst-mysql-instance-1
Migration type Migrate existing data
Start task on create Checked
Target table preparation mode Do nothing
Include LOB columns in replication Limited LOB mode
Max LOB size (KB) 32
Enable validation Unchecked
Enable CloudWatch logs Checked

在表映射方面,咱們能夠這樣設定,就不進行表名的轉換了,而後建立任務便可。

Parameter Value
Schema Tecno
Table name %
Action Include

image-20200723192925892

四、檢查目標庫數據

能夠看到,遷移任務完成,數據也都轉移過來了。

image-20200723193648100

至此咱們完成了異構數據庫遷移,整個過程會比同構數據庫遷移麻煩一些,不過總體也是比較簡單了。DMS 徹底託管、按量付費、圖形界面操做,是數據庫上雲的利器,推薦你們使用 DMS 對數據庫遷移上雲。

3、總結

AWS 數據庫優點

在衆多的雲廠商中,咱們爲何選擇 AWS 數據庫服務,AWS 還有哪些獨特的優點呢?我主要總結如下幾點:

成本優點

使用自建數據,企業首先須要支付一筆資金購買服務器,一些商業數據庫的受權,須要再次支付一筆費用。若是遷移到 AWS 的自研數據庫,客戶沒必要再支付高昂的商業數據庫受權,也沒必要再去花費大量資金去購買服務器,在雲中,客戶只須要按量付費,所以不少企業因爲把數據庫遷移到 AWS 而節省巨大費用支出。

從最近的 AWS 公告中,看到 AWS 幫助三星把數據從商業數據庫 Oracle 遷移到了 Aurora,爲三星每個月的數據庫成本下降了 44%,並讓三星的數據庫運行更加穩定。

徹底託管

以上所說的幾種數據庫都是 AWS 徹底託管的數據庫,徹底託管意味着零運維。首先客戶不須要去維護硬件的生命週期、系統的補丁更新、高可用的部署、備份等。若是須要對數據庫擴展,也只需點幾下鼠標而已,非讓方便,讓 DBA 從複雜的數據庫運維中解脫出來,專一於數據庫性能調優。

全球優點

過去咱們須要藉助很是複雜的技術手段,花費大量的成本、甚至犧牲必定的可用性,才能實現快速、穩定、安全的跨區域的數據複製,如今只要在 AWS 雲中輕輕點幾下鼠標便可完成。

AWS 雲現已在全球 24 個地理區域內運營着 77 個可用區,180個邊緣站點等,爲 AWS 相應全球數據庫提供了基礎保障。依託於 AWS 強大的基礎設施,目前已經有三款數據庫支持全球同步,延遲一般不超過 1 秒,能夠知足目前大部分應用的需求。

對於關係型數據庫的全球同步需求,Amazon Aurora Global Database 可以容許用戶輕鬆實現跨區域的數據庫部署,讓用戶輕鬆在區域之間複製數據和解決更新衝突,從而更加專一於應用程序的業務邏輯。

AWS 還提供了 Amazon DynamoDB Global Tables。它基於 DynamoDB 的全球覆蓋範圍構建,具備多區域、多主表的特性,可以讓全局分佈式應用程序實現快速的本地讀寫性能,爲用戶提供一個徹底託管的、多區域、多主的 Key-Value 類型數據庫。

針對緩存數據庫,在衆多組織都在利用 Redis 爲全球用戶提供低延遲訪問的背景下,AWS 爲更好知足客戶的需求,AWS 推出了 Amazon ElastiCache Global Datastore for Redis 全球緩存數據庫,爲用戶提供數據跨區域複製,能夠在一個區域寫入數據,同時在其餘區域讀取數據,使緩存的數據更接近用戶,減小網絡延遲,並提升應用程序的響應能力。

心得與建議

固然,數據庫遷移是一個龐大而複雜的工程,尤爲將數據庫遷移上公有云,除了數據庫知識更須要了解公有云上網絡,存儲,虛擬化等一系列知識。可是,咱們不該該僅僅將數據庫上雲看作一個複雜的任務,更應該把它當作一個優化咱們數據庫的契機,那麼上雲過程當中有哪些注意事項和建議呢?

對於一些容許停機的應用,這部分數據咱們推薦使用離線遷移,整個操做比較簡單,速度快,不容易出問題。

若是業務須要在線遷移,那麼推薦使用 DMS 進行遷移,須要注意的是,在數據庫切換以前先停掉源數據庫寫入,帶數據徹底同步到目標數據庫以後進行數據庫切換。

若是遷移的數據量比較大,建議選擇配置比較大的複製實例,這樣能夠加速咱們的複製速度。

若是您想要轉換數據庫引擎,在使用 SCT 進行 Schema 轉換的時候可能會遇到一些目標數據庫不支持的地方,請先聯繫 DBA 人員,對這些地方進行更改,知足以後再進行轉換。

相關文章
相關標籤/搜索