雲伺服器怎麼數據同步

㈠ 手機雲服務是干什麼用的

若是使用的vivo手機，可以參考以下內容：

雲服務即雲端存儲，可以備份手機照片、視頻、文檔、聯系人、簡訊、書簽等數據。在有網路的環境下，隨時隨地恢復，不用擔心數據丟失。雲服務圖標可以在手機桌面找到。

登錄雲服務：

1、打開「雲服務」APP--登錄vivo賬號--即可查看雲服務中的數據；
2、使用瀏覽器打開vivo雲服務網頁，登錄vivo賬號進行查看：網頁鏈接

使用雲服務備份，備份到雲服務方法：

入口1：桌面雲服務APP

入口2：桌面空白處下滑調出全局搜索>搜索「雲服務」

入口3：桌面設置>系統管理>備份與重置>備份數據

特別提醒：

①可能存在部分數據不支持的情況，請注意查看備份詳情與提示，確認數據是否備份成功，避免數據丟失；

②若數據備份不成功，建議可嘗試其他備份方法，如應用本身支持的雲端備份；微信數據可使用電腦端微信進行備份（微信聊天備份官方指導路徑：微信>我>設置>幫助與反饋>聊天>聊天記錄>如何備份聊天記錄）。

若有更多疑問，可進入vivo官網--我的--在線客服--下滑底部--在線客服--輸入人工客服進入咨詢了解。

㈡ 雲伺服器怎麼配置自動時間同步

時間同步命令：
ntpdata time.windows.com
自動時間同步：
需要配置/etc/crontab文件，實現自動執行任務
讓linux從time.windows.com自動同步時間
vi /etc/crontab
加上一句：
00 0 1 * * root ntpdate -s time.windows.com
time.nist.gov 是一個時間伺服器.
Linux時間伺服器配置(192.168.10.1)
1）. # rpm -ivh ntp-4.1.2-4.EL3.1.i386.rpm

2）. # vi /etc/ntp.conf
注釋一行
restrict default ignore
加入一行
restrict 192.168.10.0 mask 255.255.255.0 notrust nomodify notrap
3）. # vi /etc/ntp/step-tickers
加入一行
pool.ntp.org
這樣每次ntpd啟動時，會自動連接該國際標准時間伺服器；
4）. # service ntpd start
5）. # netstat -an |grep 123
確保該埠以udp方式開放
時間客戶端配置(192.168.10.2)
1）. # ntpdate 192.168.10.2
應該顯示同步成功
2）. # crond -e
加入
0-59/10 * * * * /usr/sbin/ntpdate 192.168.10.1
表示每隔10分鍾同步一次時間

㈢ 雲伺服器與雲伺服器該怎麼遷移數據

在支持京東集團內部及京東雲外部客戶的業務遷移到京東公有雲及京東私有雲、京東政務雲的過程中，京東科技-京東雲事業群-技術服務組積累了相關業務系統數據遷移的一些管理和技術經驗，以案例的形式分享給大家，希望對大家的業務遷移工作有所幫助。

業務遷移上雲涉及到的業務數據種類繁多，主要類型包括： 資料庫： 關系型資料庫 MySQL 、PG、Oracle等 對象存儲： 標准S3介面對象存儲遷移中間件數據：ES、mongoDB、redis等 文件存儲：文檔、圖片等非結構化數據 大數據：HBASE、HDFS files等。

在上雲過程中，大部分業務均涉及到以上多種數據類型，基於相關遷移的案例所積累的經驗，數據遷移需要在遷移啟動前至少做好如下准備工作。 數據遷移技術方案制定完成，包含明確的遷移操作步驟、執行人、確認人。 制定遷移應急預案及回切方案，明確責任矩陣，確認異常情況的決策條件及決策人。 確認數據安全等級，確認數據遷移的方案合規安全，通過相關業務安全部門審核。 遷移時長及割接數據同步窗口的評估，確認各個業務及數據遷移可選的第二方案。 確認網路帶寬及質量滿足遷移需求。

下面是幾個案例，涉及到了不同數據遷移的場景。 關系型資料庫遷移：MySQL 數據遷移工具DTS服務在傳輸及同步、數據校驗等步驟實現了一定的抽象化，具有相對友好的交互界面，同時可以實現多個任務並行進行，對要求平滑遷移的場景，具有自動化優勢，節省大量人力，但需要滿足源端資料庫與目標端資料庫與DTS管理服務IP網路互通，並具備穩定的網路連接。 mysqlmp工具適合於網路連接不佳或需要一定業務中斷時間的場景，本地操作速度快，但需要考慮數據文件的傳輸時間。 DTS與mysqlmp工具都有各自的限制條件，需要仔細閱讀產品說明，並通過POC驗證功能。

案例一：從友商公有雲遷移到京東雲公有雲，由於源端binlog問題導致DTS任務失敗，最終通過mysqlmp模式導出文件，本地導出速度很快，壓縮後的資料庫導出文件體積縮小，減少了網路傳輸耗時。通過網路傳輸到京東雲側的雲主機，然後source方式導入RDS，整個過程耗時小於2小時。導入MySQL數據後，使用checksum_table工具對源端和目的端資料庫做對比，發現部分表不一致，與業務方確認為源端在遷移開始後，停止服務不徹底導致，仍然有數據寫入操作，後經業務及研發檢查新增數據，對部分數據做清理後，完成資料庫的遷移工作。

廠商改良（非原生）的資料庫的遷移：在某些雲廠商的特定資料庫版本中，會對標準的資料庫產品如mariaDB、PG等資料庫做一些定製化的開發，以滿足客戶的業務的某些特殊需求，這種資料庫屬於廠家深度綁定的類型，在做業務遷移或災備數據同步的時候，根據時間場景做定製化的遷移及同步方案，大部分需要從研發層面做一些定製化的配置和操作。

案例二：某金融用戶，原系統運行於T的金融雲，使用了定製化的RDS服務，因金融行業的業務及數據災備規范，需要做異地容災，將災備系統運行於京東金融雲平台。為實現從T雲定製化的TDSQL到京東雲的遷移，對源端的資料庫做了詳細調研，因為源端是定製化的、具有自動水平拆分、Shared Nothing 架構的分布式資料庫，因此使用京東雲的DTS工具不適用於這個場景，同時，在兩個環境，要求數據基本為實時同步才能滿足業務容災的需求。制定方案時，考慮了傳統災備廠商的方案，但因傳統廠商災備方案多以主機級別數據及IO分析或日誌分析為基礎，無法適應雲上RDS的場景，最終方案採取了基於gtid的主從復制的方案來實現資料庫的異構雲同步。

案例三：客戶業務從友商雲遷移到京東雲，源端ES為K8S集群自建服務，服務訪問方式為nodeport方式，選擇遷移技術方案時，考慮了源端自建的ES未安裝S3插件，因此採取reindex方式來做業務數據的遷移。為實現從京東雲側對ES的數據拉取，在源端配置了一個nginx反向代理，實現了通過公網對內部ES介面的訪問，同時配置白名單，限制訪問IP為京東側NAT網關出口的公網IP，確保數據的訪問安全。在京東雲側，臨時調整路由表，配置明細路由，將源端公網IP配置到對應子網的路由表中，指向NAT網關，通過NAT網關可以拉取到源側的ES數據，並在ES服務中對源端的公網IP做加白操作。

對象存儲的遷移：對兼容S3協議的對象存儲數據遷移，各個公有雲廠商均有遷移工具或腳本，遷移技術難度不高。但是，因為不同廠家的對象存儲在不同region可能存在底層版本及配置差異，因此需要對遷移的數據做完整性和可用性校驗。在實際遷移中，需要根據項目實際的數據存儲量、業務訪問特性、業務停機窗口等信息，綜合考慮遷移流程和選擇技術方案。

Redis遷移：業務中Redis使用有兩種場景，一種是僅作為緩存，不做數據持久化，這種業務場景，遷移後在新環境部署業務後直接調整業務指向新的redis實例即可。一種是有數據持久化，這種業務在遷移到雲上時，需要根據業務需求，做redis數據的遷移操作。Redis有rdb（point-in-time snapshot）和aof兩種持久化方案，其中rdb模式是二進制格式，類似於快照，恢復直接覆蓋，aof保存的是命令（文本格式），類似於追加模式。如果需要保留目標端的redis的數據，可以使用aof方式，但需要注意老版本Redis服務不兼容新版RDB格式。

數據備份的重要性：數據備份是在業務遷移的全生命周期怎麼強調都不過分的環節，因數據備份不充分導致數據丟失、業務受損的教訓很多。在遷移實施過程中，因忽視數據備份而導致出現問題的事件仍然很常見。問題可能來自客戶，可能來自我們實施團隊，也可能來自ISV或者其他可能操作數據的團隊或個人。在重要業務場景中，遷移前，需要對數據備份所需的存儲空間做好評估並考慮備份空間的成本。

業務數據遷移總結：提前做好備份，有了備份數據，遷移過程的壓力會減小，相對寬松的遷移氛圍對遷移實施很有利。遷移技術及工具的選擇，需要根據業務性質選擇並驗證。准備回退預案，做好POC驗證，POC能發現部分問題，提前准備解決方案。做好流程手冊，明確操作責任人，聯系相關部門做好遷移的切換階段的護航准備。產品和服務類的問題一定要能找到人支持。明確責任矩陣、進行全面溝通，溝通能夠發現技術層面很難發現的問題，越早建立遷移組織並形成有限的溝通機制，對遷移的順利實施越有利。

致謝：本文寫作過程中，京東科技-京東雲RDS研發同事、京東科技-京東雲對象存儲研發同事、京東零售-企業業務事業群的研發同事提供了寶貴資料和建議。向他們表示衷心地感謝。