रूबी ऑन रेल्स + लीगेसी_मिग्रेशन: दो परियोजनाओं के बीच एकतरफा डेटा सिंक्रोनाइज़ेशन

इस लेख का उद्देश्य एक गैर-तुच्छ समस्या के समाधान का वर्णन करना है - रूबी ऑन रूल्स , लीगेसी_मिग्रेशन हेम और अपेक्षाकृत सीधे हाथों का उपयोग करके दो परियोजनाओं के डेटाबेस में स्वचालित एक-तरफ़ा डेटा सिंक्रनाइज़ेशन।

प्रारंभिक स्थिति

एक गंभीर भारोत्तोलन के बिना कई चरणों में 3 वर्षों में एक भरी हुई परियोजना है, यही वजह है कि कोड में सूजन है और उपयोग की जाने वाली प्रौद्योगिकियां काफी पुरानी हैं। सब कुछ नया करने के लिए परियोजना को फिर से लिखना शुरू करने का निर्णय लिया गया।

पुराना प्रोजेक्ट:

• रेल 2.3.4 (बाद में बंडलर के माध्यम से 2.3.12 + निर्भरता नियंत्रण के लिए उन्नत)
• MySQL 5
• स्फिंक्स, विलंबित नौकरी, एआर प्रेषक, इंटरलॉकिंग + कैशिंग के लिए और बाकी चीजें

नई परियोजना:

• रेलगाड़ी 3.1.0.rc5 (वर्तमान में)
• Postgresql 8.4 (शायद 9 बाद में)
• अभी भी छोटी चीजों के बारे में बात करना जल्दबाजी होगी, लेकिन सोल्र , रेडिस , रेसक को माना जाता है

मुख्य कठिनाई एक नई परियोजना में पुराने डेटाबेस आर्किटेक्चर से दूर जाने की क्षमता के साथ डेटाबेस सामग्री का सिंक्रनाइज़ेशन है। बहुत सारे विकल्पों पर विचार किया गया था, लेकिन चुने हुए ने अंततः एक स्वचालित सामग्री सिंक्रनाइज़ेशन सिस्टम बनाया जो रिकॉर्ड आईडी बचाता है, रिकॉर्ड टाइमस्टैम्प बचाता है, नए लोगों को जोड़ता है और मौजूदा अपडेट करता है। और इस सब के साथ, यह आपको मौजूदा डेटाबेस के स्कीमा को सख्ती से कॉपी करने के लिए बाध्य नहीं करता है ।

मणि विरासत_मिश्रण

अर्ध-तैयार समाधान की खोज की प्रक्रिया में, एक सुविधाजनक मणि पाया गया (ror2ru समूह की मदद के बिना नहीं), रेल 2.3.x के दिनों में वापस लिखा गया, जो आपको एक मॉडल के मनमाने गुणों की सामग्री को दूसरे पर स्थानांतरित करने की अनुमति देता है, उन पर मनमाना संचालन करने की क्षमता के साथ। यह एक अच्छी शुरुआत थी, लेकिन परीक्षण प्रक्रिया के दौरान, महत्वपूर्ण कमियों की खोज की गई:

• आईडी रिकॉर्ड सहेजे नहीं गए थे (उसने डेटाबेस में आइडी = 1 से शुरू होने वाली पंक्ति में वस्तुओं को ढेर कर दिया था)
• अस्थायी रिकॉर्ड स्टैम्प सहेजे नहीं गए थे (अद्यतित_एट, निर्मित_त)
• जब रेक कार्य को फिर से चलाया जाता है, तो नई आईडी के तहत तालिका में डेटा को डुप्लिकेट किया गया था

मैं इस बात पर ध्यान केंद्रित करना चाहता हूं कि तत्वों की आईडी क्यों रखनी है, इसके लिए निम्न तरीका है - इस पर पुराने आईडी और फिर से नई आईडी को फिर से बाँधने जैसी विशेषता बनाने के लिए। लेकिन कार्य केवल एक नई परियोजना बनाने के लिए नहीं है, बल्कि पुरानी परियोजना को एक नए के साथ बदलने के लिए है, और यह कम से कम सभी यूआरएल की पहचान का अर्थ है। यह समझने के लिए कि यह कितना महत्वपूर्ण है, यह सड़क पर एक एसईओ विशेषज्ञ को पकड़ने के लिए पर्याप्त है और इस बारे में बात करता है कि आप एक कार्यशील परियोजना पर यूआरएल कैसे बदलना चाहते हैं। एक अस्पष्ट प्रतिक्रिया का पालन करना चाहिए, जो स्वयं को विभिन्न रूपों में प्रकट कर सकता है - बेहोशी से लेकर मनोविकार तक :)
पहचानी गई कमियों को खत्म करने के लिए, मैंने यह कांटा बनाया। यह समझने के लिए कि यह क्या है, मैंने लिखा है कि आप यहाँ अनुसरण कर सकते हैं ।
यह ध्यान दिया जाना चाहिए कि एआर मॉडल के माध्यम से डेटा स्थानांतरित करने की विधि में एक महत्वपूर्ण कमी है - कम प्रदर्शन, लेकिन मेरे मामले में डेटाबेस अपेक्षाकृत छोटा (कुल लगभग 400 एमबी) निकला, और सर्वर इस दृष्टिकोण को नहीं छोड़ने के लिए पर्याप्त शक्तिशाली है।

स्थानांतरण प्रक्रिया

इसके साथ शुरू करने के लिए, यह ध्यान दिया जाना चाहिए कि मैं पुरानी परियोजना को आगे बढ़ाते समय भाग्यशाली था (और 2.3.4 से 2.3.12 तक रेल संस्करण को समानांतर रूप से उन्नत करता था), दोनों परियोजनाओं के डेटाबेस एक ही सर्वर पर थे - आवधिक सिंक्रनाइज़ेशन के लिए बेहतर कुछ नहीं है।

आवश्यक रत्न स्थापित करना

पहले आपको यह सुनिश्चित करने की आवश्यकता है कि दोनों DBMS के लिए एडेप्टर Gemfile में दर्ज किए गए हैं:

gem 'mysql2' gem 'pg' 

विरासत सेट करने के लिए दो विकल्प हैं_स्मरण - कांटा (जो पहले से ही आवश्यक बदलाव कर चुका है) या मूल मणि इसे मैन्युअल रूप से समाप्त करने की क्षमता के साथ (मैं क्रमशः दोनों विकल्पों के लिए जेमफाइल से लाइनें उद्धृत करता हूं):

 gem 'legacy_migrations', :git => 'git://github.com/Antiarchitect/legacy_migrations.git' gem 'legacy_migrations', :path => 'vendor/gems/legacy_migrations-0.3.7' 

जिसके बाद आप अपने आप को कोड में परिवर्तन कर सकते हैं, और मणि मार्ग में प्रकट होने के लिए, आपको अपने आदेश की जड़ में इस कमांड को चलाने की आवश्यकता है:

 gem unpack legacy_migrations --target vendor/gems 

कार्य सिद्धांत

लीगेसी_मिग्रेशन का सार निम्नलिखित है: प्रोजेक्ट में ऐसे मॉडल होने चाहिए जिनसे हम डेटा और मॉडल लेते हैं जिसमें हम इन रिकॉर्ड्स को मिरर करते हैं। इस प्रकार, नए प्रोजेक्ट का config / database.yml कुछ इस तरह दिखेगा:

 production: adapter: postgresql encoding: utf8 database: newapp_production username: postgres password: somecomplicatedpassword legacy: adapter: mysql2 encoding: utf8 database: oldapp_production username: root password: anothercomplicatedpassword 

जहां विरासत पुराने प्रोजेक्ट के आधार के लिए कॉन्फ़िगरेशन है (नाम को मनमाने ढंग से चुना जा सकता है)।
अगला, आपको पुरानी परियोजना के मॉडल को देखना चाहिए और आगे भ्रम से बचने के लिए एक मुक्त उपसर्ग चुनना चाहिए। मेरे मामले में, यह उपसर्ग "पुराना" था। उसके बाद हम डायरेक्टरी ऐप / मॉडल / पुराना बनाते हैं और अमूर्त वर्ग को वहाँ रखते हैं, जहाँ से अन्य सभी को विरासत में मिलेगा। उदाहरण ऐप / मॉडल / पुराना / पुराना_बेस / आरबी:

 class OldBase < ActiveRecord::Base self.abstract_class = true establish_connection 'legacy' end 

जहां तर्क 'विरासत' को विन्यास / डेटाबेस में पुराने डेटाबेस के लिए सेटिंग समूह के नाम से मेल खाना चाहिए। इस प्रकार, ओल्डबेस वर्ग (और सीधे ActiveRecord :: Base) से विरासत में मिले सभी मॉडल को पता होगा कि किस डेटाबेस से जुड़ना है। निम्नलिखित एक ऐसे मॉडल का एक उदाहरण है:

 class OldNewsDoc < OldBase set_table_name 'news_docs' end 

चूंकि हमारी कक्षाओं में अब एक उपसर्ग है जो मूल रूप से इरादा नहीं था, आपको सीधे तालिका का नाम निर्दिष्ट करना होगा।
एप्लिकेशन / मॉडल / पुराने से कक्षाओं के लिए स्वचालित रूप से लोड होने के लिए, आपको इस पथ को इस तरह से कॉन्फ़िगर / एप्लिकेशन में दर्ज करना होगा:

 module NewApp class Application < Rails::Application ... config.autoload_paths += %W(#{config.root}/app/models/old) ... end end 

और फिर एक रेक कार्य बनाने के लिए सब कुछ बहुत आवश्यक है, उदाहरण के लिए यह एक (lib / कार्य / विरासत ।rake):

 require 'legacy_migrations' namespace :legacy do namespace :transfer do desc 'Transfers News Docs from onru to onru2' task :news_docs => :environment do transfer_from OldNewsDoc, :to => NewsDoc do from :id, :to => :id from :updated_at, :to => :updated_at from :created_at, :to => :created_at from :news_rubric_id, :to => :news_rubric_id from :title, :to => :title from :annotation, :to => :annotation from :text, :to => :text end end end end 

यह बात है - अब इस तरह कार्य शुरू किया जा सकता है:

 bundle exec rake legacy:transfer:news_docs RAILS_ENV=production 

इस लेखक की पोस्ट में पढ़ने लायक विरासत की संभावना के बारे में और पढ़ें।

प्रक्रिया स्वचालन

संभावित विकल्प हैं, क्योंकि रेक कार्य पहले से ही मौजूद है और इसे कैसे लॉन्च किया जाए यह दसवां मामला है, हालांकि मैं उस परियोजना के लिए समय-समय पर किसी भी कार्य को शुरू करने का विकल्प पेश करना चाहूंगा जो मुझे सबसे ज्यादा पसंद आया।

जब भी मणि

एक बहुत ही सुविधाजनक रत्न है - जब भी - क्रोन के माध्यम से एप्लिकेशन की जरूरतों के लिए स्वचालित रूप से कार्य शुरू करने के उद्देश्य से, जिसे आसानी से कैपिस्ट्रानो में एकीकृत किया जा सकता है और आपको एक विशिष्ट उत्पादन वातावरण में बुनियादी चीजों (जैसे रेक कार्य, धावक या कंसोल कमांड) के लॉन्च को समायोजित करने और अपने स्वयं के प्रकार लिखने की अनुमति मिलती है। कार्य किए।
ऐसा करने के लिए, आपको जब भी (Gemfile की एक पंक्ति) स्थापित करना होगा:

 gem 'whenever', :require => false 

एप्लिकेशन रूट से कमांड चलाएं

 wheneverize . 

और नव निर्मित config / schedule.rb फ़ाइल में निम्नलिखित डालें:

 job_type :rake, "rvm use ree && cd :path && RAILS_ENV=:environment bundle exec rake :task :output" if environment == 'production' every :day, :at => '2am' do rake "legacy:transfer:news_docs" end end 

मैं अपने पर्यावरण के लिए रेक कार्य की परिभाषा को फिर से लिखता हूं: मैं कस्टम इंस्टॉलेशन आरवीएम का उपयोग करता हूं और एक रूबी दुभाषिया के रूप में पुन: उपयोग करता हूं (जैसे ही रेल 3.1 स्थिर हो जाता है मैं 1.9.2 पर स्विच करता हूं - जबकि कुछ समस्याएं हैं), मैं भी बॉलर का उपयोग करता हूं, इसलिए किसी भी बाइनरी या स्क्रिप्ट का उपयोग करना चाहिए बंडल निष्पादन के माध्यम से चलाएं।
यह कैपिस्ट्रानो में एकीकृत होता है जब भी आसानी से और स्वाभाविक रूप से (तैनाती। आरबी):

 require 'whenever/capistrano' ... set :whenever_command, "bundle exec whenever" #  ,   bundler -      whenever 

तैनाती के बाद, आप कोंट्राब में सुंदर और साफ लाइनों की प्रशंसा कर सकते हैं:

 crontab -l 

पीएस मुझे उम्मीद है कि एक परियोजना से दूसरी परियोजना में डेटा स्थानांतरित करने की समान समस्या से जूझ रहे लोगों के लिए यह लेख उपयोगी होगा।

एंड्रे वोरोकोनोव , इवरोन डॉट कॉम ।