一千萬個為什麽

搜索

哪些實踐或工具可以實現數據庫的連續部署?



與為數據庫嘗試相同的方法相比,持續交付或持續部署基礎架構和代碼相對簡單,尤其是RDBMS。一旦部署完成,代碼和基礎架構不會改變或演變。然而,數據庫將有新的數據添加到他們的數據中,如果不是模式固有的可變組件。

我知道有些做法只是添加數據庫對象,即表和列,從不修改或刪除它們 - 這種接近數據庫模式的純粹的附加方式具有確保模式向後兼容的優勢,但代價是相對復雜模式。

同樣有產品,例如 Flyway準備就緒”,這有助於編寫模式版本之間的遷移。

目前還有哪些其他實踐和工具可以將數據庫模式連續部署到數據完整性受到關註的生產環境中?

轉載註明原文: 哪些實踐或工具可以實現數據庫的連續部署?

一共有 6 個回答:

Pramod Sadalage和Scott Ambler寫了一本重構數據庫:演化數據庫設計,這是一個令人難以置信的堅實在CD組織/團隊中引入DB的主題。

挑戰


我知道有些做法只是添加數據庫對象,即表和列,從不修改或刪除它們。

在我工作的一家公司,原始數據的滾動窗口等同於大約6個月,吃了10TB。然後將數據處理成RDBMS格式,其耗費6TB的可用數據,其中約10年的可報告數據。重要的是,從規模上看,這種做法根本不是“ 實用。存儲成本很高 - 可能是最大的計算費用。這提供了幾個有趣的挑戰:

  1. Backups - the innodb plugins are great and all, but the backup times on that much data just aren't that practical
  2. Restore times - for large datasets - especially if you need replication to catch up after a restore getting back to an operational state can take days or even weeks
  3. Creating/seeding new instances - Often the work you may be doing in dev/test involves ETL (Extract, Transform and Load) jobs on your dataset. These need to be validated using QA testing units, but this needs to be done in a non-destructive manner so that the origional production dataset is preserved. While in a disaster, you may be willing to deal with a long restore time on the understanding that backups are an insurance policy and the intent is to avoid them, the DevOps development workflow requires that, essentially, you be able to perform a restore or copy of your data on a regular basis (perhaps multiple times a day)
  4. Capacity - Slinging around that much data at the scale I just described can be very I/O intensive. No only do you need to address the problems described in 1-3, but you need to do it in a way that doesn't cause outages or performance slowdowns to your production systems.

While the above considerations may not be a concern at smaller scales, at larger scales, these become huge problems. This means that it is extremely important that you define your requirements and forecast the size of your dataset.

定義需求


因此,您需要定義幾個要求:

  1. RTO - RTO or Restore Time Objective for backups are one of the most important drivers of database backup solutions. While, at first it might not appear relevant to most of the other problems, it becomes extremely relevant when you ask "What if I used my backup solution for creating or seeding new instances?". I'll cover some techniques for doing so in the next section.
  2. RPO - RPO or Restore Point Objective for backups defines A) how far back you are able to restore (minutes, hours, days, weeks, months, or years) B) The backup interval at different tiers and C) how granularly you can restore. For example, for E-mail databases, Message Level Backups - restoring a specific E-mail - are often sought. Similarly, you may find that data over a few days is completely useless - so there is no point restoring back a year.
  3. Size of your dataset - This is important because for a 1MB database, your RTO may be achieved with most backup products and solutions. For a 10TB database however, you will find that a full, row level backup to LTO 3 tape probably won't achieve your RTO and could interfere with your RPO because backups begin exceeding your backup window. You can't exactly just do a mysqldump on this large of a dataset, but could probably get away with that on the 1MB database.
  4. Database consistency - A final thing that makes an immense difference in continuous deployment, site reliability, scalability and high-availablity when working with databses is your need (or lack thereof) for consistency. There are three basic types: immediate consistency, Just-In-Time (JIT) consistency and eventual consistency

除了上述主要考慮之外,您還需要考慮許可和支持要求(開源或封閉源代碼;內部支持,第三方支持或供應商支持)應用程序/語言要求(許多數據庫的連接器可能很重要;是您的應用程序是否已編譯?您是否可以訪問源代碼?您可以重新編譯它,還是由供應商提供?還是以解釋型語言運行?)政治要求(您的組織是否只信任Oracle?他們是否恨甲骨文?他們不相信MySql?你對MariaDB或Postgres有什麽看法?)和數據庫引擎(innoDB?MyISAM?Blackhole?NDB Cluster?Spider?)以及歷史或兼容性要求(我們使用PL/SQL多年和一半的代碼內置於oracle引擎中!我們怎樣才能移植到MariaDB?!?)

All of these things (significantly) impact the tools available to you.

內部數據管理的一些選項


註意:以下內容絕不是詳盡無遺的,其他SE用戶應該加入其他建議。

考慮到一般的考慮因素,讓我為您提供解決上述問題的一些技術和技術。首先,問問自己是否真的需要來使用RDBMS,或者如果非結構化數據具有Hadoop,CouchDB或甚至面向對象的存儲(類似於swift)是一種選擇。

其次,考慮查看基於雲的解決方案。這些外包出現了一些令人頭痛的問題,並將復雜的問題留給了高素質(和付費)的個人。然而,在規模上,您可以發現這確實能夠滿足您的預算要求(雲提供商可以從中獲利,並且在一定規模上,您可以承擔自己聘請這些專家的責任),或者如果您在特定安全或政治環境下工作要求(閱讀:我們不能做雲)考慮一個混合NFS/FibreChannel Filer。這些文件管理器大多數(如NetApp,Pure Storage和Tegile的文件管理器)都支持基於增量的快照和克隆技術,可以非常方便地進行A)備份,B)恢復備份和C)為新備份播種。

在這一點上,我需要指出的是,我不是備份和存儲專家,因此在轉移到其他問題(和更加環保的牧場)之前,我從未完全解決過這個問題的某些部分。

But that being said, these products allow you to take differential snapshots underneath your databse. You will need to script out a full "lock tables with read lock" on one of your database instances (a read-only slave is recommended) and dump your binlog position or GTID but for these filers, once you do, you will be able to use these snaps to create new instances of your database. You will want to put binlogs on a seperate partition and put only your database data on these partitions. Once you do, you will be able to clone these partitions (on NetApps, this is know as a "FlexClone") The only issue with these is that they cannot span datastores which means that all your I/O is still impacting the same datastore/volume and calculating deltas can cause some overhead in terms of CPU resources.

這是因為對於每個塊讀取,文件管理器必須確定數據是否駐留在凍結的原始快照中或增量中。對於具有多個快照的卷/商店,可能需要多次檢查。您可以通過刷新數據來解決此問題(意思是放棄快照並定期再次克隆它 - 這可能會自然而然地發生,以實現良好的連續部署環境)或通過永久拆分卷(NetApp術語中稱為“Flex拆分” ),這將需要一些時間來永久解決三角洲問題,並創建一個全新的,獨立的卷。

這些增量克隆具有減少總體存儲需求的額外好處 - 您可以產生多個克隆或生產數據庫數據實例,以進行開發,測試和驗證。如果您只保留大型數據集的一個副本以及(可能會有的)小的增量,則可以降低整體存儲成本和占用空間。

唯一的竅門是,這可能不構成完整的備份解決方案,因為“備份”仍駐留在您的文件管理器上。為此,您可能需要使用NetApp所稱的快照鏡像,它將在文件管理器甚至數據中心之間鏡像數據(使用rsync樣式的技術),或者使用某種類型的集成備份解決方案,可以備份到磁帶上的某個增量快照或柔性克隆。

然而,這有一個主要缺陷:所有的數據 - dev,test和prod都是在同一個filer和存儲頭上使用I/O。要解決此問題,請考慮在第二個Filer上創建一個從屬數據庫實例,該實例可以作為Test和/或dev filer的種植點,或者考慮為應用程序層使用負載平衡器/應用交付控制器,以將生產請求鏡像到您的測試(和/或開發)環境。這在將產品流量投放到QA /測試環境中之前還有一個好處,那就是在生產中可能不會立即發現問題。然後,您可以根據生產流量和用戶行為檢查日誌中的錯誤。

然後這應該允許您使用幾個腳本以編程方式產生並銷毀整個(和大型)數據集以供連續部署方法使用。 點擊 點擊

可擴展性和高可用性

While you asked about continuous deployment, DevOps is conserned with more than just continuous deployment - so I am going to include some bits about redundancy, 可擴展性和高可用性.

我提到了JIT,即時和最終的一致性。這就是各種各樣的RDBMS引擎出現的地方。通過簡單配置循環異步復制,最終的一致性相對容易。然而,這可能會導致一些沖突*(如果應用程序層在復制完成之前更新群集一側和群集另一側的數據,會出現什麽情況?)為了保持一致性,請查看將強制進行同步復制的Galera群集,但會導致可擴展性問題(您將如何復制到災難恢復站點或在地理上負載平衡,而不會由於網絡層的推遲延遲而導致嚴重的延遲?)您還可以查看是否可以在數據中心內執行同步復制以及站點之間的異步復制,但這似乎是兩個世界中最糟糕的。

然而,通常情況下,大多數人並不需要完全同步復制 - 這通常只用於非常特殊(和異國情調)的高寫入環境,在這種環境中需要使用表分片的多主機。大多數應用程序可以使用數據庫代理來處理實時一致性。例如, ScaleArc 將監控復制狀態並跟蹤剛剛寫入的位置(發送次要讀取請求,直到復制趕上)提供數據庫一致性的即時一致性和外觀。 ScaleArc與Postgres,MySQL,MariaDB,Oracle和MSSQL兼容,並且可以使用正則表達式為不能使用分片鍵的應用程序分割/分割數據庫。它還具有一個強大的REST API,供您的配置管理軟件與之交互 - 而且他們的支持團隊非常出色

同樣,您可能希望考慮MariaDB團隊為MariaDB開發的免費替代方案,即 MaxScale 。它缺少GUI和ScaleArc的一些緩存功能。

最後,MySQL結構(以及只有in-RAM的MySQL簇 - 如果你能承受那麽多的RAM)是其他潛力 - 尤其是在MySQL的新代理中。這可以為您的環境提供可伸縮性和冗余組件。

Postgres和Oracle應該有你需要的復制和分片功能,但是如果你需要一個代理,ScaleArc會配對。

最終,如果您無法簡單地使用基於雲的環境並讓您的雲提供商為您處理上述問題,則所有這些附加功能都可以構建適合持續部署和開發的高度靈活的環境。

我認為,除非將模式職責轉移到應用程序團隊,否則單靠一個工具不會真正起到幫助作用。

我們確實使用 liquibaseflyway 工作,應用程序團隊負責創建變更集。

除此之外,你可以避免純粹的添加方式 每個應用程序都需要與其先前版本兼容,當必須完成模式更改時,應用程序將在模式中集成一個新列,寫入並繼續讀/寫前一列(允許以前的版本仍然有相同的數據) 允許下一版本的應用程序停止更新舊列,只允許第三個版本刪除現在未使用的列。

顯然,如果出現問題,需要定期備份 可能會在集成測試中產生問題以避免它們在生產中的適當子集的數據也是一個好主意。理想情況下獲得生產數據的匿名子集。

To answer this question in the context of a mainframe environment, and specific to DB2® databases, there are typically 2 commonly used (not cheap ...) alternatives to pick from:

  • Object Administration for DB2®, from BMC. Here are some details about it (quote from the linked page):

    Making changes to objects in your database—or even just performing routine administrative tasks—can be difficult, risky work. There are dozens of tasks to keep track of, and a single misstep could have a disastrous impact on availability and data integrity. You can cut back on both effort and risk with BMC Object Administration for DB2 11, a collection of tools to help you:

    • Reduce the time required to administer complex and disparate DB2 environments.
    • Automate routine tasks throughout the application lifecycle for improved integrity.
    • Improve productivity with simplified DB2 catalog navigation and change management.
    • Enhance application availability by performing changes and maintenance with minimal outages.
  • DB2 Administration Tool for z/OS, from IBM.

    It simplifies the complex tasks associated with safely managing DB2 objects and schema throughout the application lifecycle with the least possible impact to availability.

    • Allows users to navigate the DB2 catalog quickly and easily
    • Builds and executes dynamic SQL statements without knowing the exact SQL syntax
    • Manages and tracks changes made to DB2 object definitions resolving any potential conflicts prior to execution
    • Helps build DB2 commands to execute against databases and tables
    • Enables users to create, alter, migrate, drop and reverse engineer DB2 objects
    • Builds and executes utility jobs, allowing users to take advantage of LISTDEFs and TEMPLATEs for increased productivity

與SCM工具集成

前一段時間,我被一位客戶挑戰,實際將BMC備選方案“整合”到他們的SCM生命周期中(由 SERENA ChangeMan ZMF )。這種整合背後的想法是“考慮我們的DB2 DBA團隊(用DDL做東西)作為開發團隊的一個特例,偶然使用一些特殊的編輯器(BMC工具)來生成代碼(DDL)遷移”。

關於這種集成的唯一(但是 real !)挑戰也促進了“可重啟性”,這是這種DBA工具的主要優勢之一:

    可重新啟動性意味著當這個DBA工具正在做它的事情時(根據待完成工作的性質,通過有時長時間運行的工作),可能會發生意想不到的事情(死鎖,時間縮短等)。
  • 如果發生這些情況,並且您不想從備份中重新啟動(在啟動之前),那麽DBA工具希望您從開始啟動的(檢查)點重新啟動出問題了(從你想要的地方重新執行)。

  • 還是更好(或者我應該說“更糟糕”?),如果DBA工具的新用戶不知道如何從這種檢查點重新啟動,並且只是再次嘗試(從頭開始),那麽DBA工具只會因某種用戶錯誤而失敗。而且這裏有一個像“”這樣的指示,直到你告訴我你希望我在我最後一次失敗後繼續前進,我拒絕做任何事情(不要讓事情變得更糟)“。 p> 最後,在所用的SCM工具中實現這種可重啟性的真正線索,也需要調整SCM工具。實際上,它允許它用於重新啟動失敗的SCM過程(通常與傳遞到目標測試/產品環境有關)......而不是僅僅提交失敗的SCM過程(這是通常這些SCM工具從這種情況中恢復的方式)。

Bonus: after the SCM integration of the BMC alternative got completed, the customer decided to change their DBA tool to the IBM alternative. And even though both alternatives don't really look the same, the impact of it to the SCM integration was rather minimal: simply a matter of replacing (in some reusable SCM customization) some calls to the BMC alternative by the equivalent calls to the IBM alternative ... which (using DevOps terminology) got implemented by /.

我們在我們的工作中使用 liquibase ,我會為此高度評價。它也被我們的QA工具 QASymphony 使用。

我們正在利用它針對內部的MSSQL和Oracle數據庫,並且QASymphony使用/已經將它用於postgres + mysql實例。

我們在工作中使用 Flyway 來管理應用中的Postgres模式,以及“rel =”nofollow noreferrer“>支柱。如果應用管理自己的模式,我們發現它是最好的。

We had a horrible experience having manage schemas before the apps managed their own schemas.