4.3.3 Maak 'n Differensiële of inkrementele rugsteun Veronderstel 'n goeie gedeelte van die data op jou MySQL bediener bly onveranderd met verloop van tyd, kan jy die spoed te verhoog en verminder die vereiste stoorplek vir jou gereelde rugsteun deur die back-up nie al die data op die bediener elke keer, maar slegs die veranderings aan die data wat plaasvind met verloop van tyd geneem het. Uitvoering van 'n reeks van differensiële rugsteun: Ten einde dat, nadat eers 'n volledige rugsteun dat alle data bevat, kan jy een van die volgende te doen. Elke ewenaar rugsteun sluit al die veranderinge wat aan die data sedert die laaste volle rugsteun is uitgevoer. Om data te herstel tot, byvoorbeeld, tyd t. jy net herstel eers die volle rugsteun, en dan, op die top van dit, die ewenaar Friends geneem vir tyd t. Voer 'n reeks van inkrementele rugsteun. Elke inkrementele rugsteun sluit slegs die veranderinge sedert die vorige rugsteun, wat op sy beurt 'n volle of inkrementele rugsteun kan wees. Die eerste Friends in 'n toenemende reeks is altyd dan 'n differensiële rugsteun maar daarna elke inkrementele rugsteun bevat slegs die wysigings sedert die laaste inkrementele rugsteun. Elke daaropvolgende inkrementele rugsteun is dus gewoonlik kleiner as 'n differensiële rugsteun, en is vinniger om te maak wat jou toelaat om baie gereeld inkrementele rugsteun te maak, en dan kan jy die databasis te herstel na 'n meer akkurate tydstip wanneer dit nodig is. Dit is egter moontlik herstel data met inkrementele rugsteun meer en meer werk te neem: in die algemeen, om data te herstel tot, byvoorbeeld, tyd t. jy begin met die herstel van die volle rugsteun, en dan die herstel van die inkrementele rugsteun een vir een, totdat jy klaar is met die inkrementele rugsteun geneem vir tyd t. MySQL Enterprise Backup ondersteun beide inkrementele en differensiële rugsteun. Jy moet besluit watter Friends strategie aan te neem deur te kyk na sulke faktore soos hoeveel stoorplek jy het, hoe vinnig jy moet in staat wees om data te herstel, en so aan. MySQL Enterprise Backup behandel ewenaar Friends as 'n spesiale geval van inkrementele rugsteun dat 'n volledige rugsteun as sy basis het. Om 'n differensiële rugsteun te skep, volg net die instruksies hieronder vir die uitvoering van inkrementele rugsteun, en maak seker dat jy 'n volledige rugsteun as die basis van jou inkrementele rugsteun spesifiseer met behulp van die metodes wat ons beskryf onder julle moet ook enige instruksies wat net van toepassing is op die hantering van ignoreer verskeie inkrementele rugsteun. Wanneer die skep van 'n inkrementele rugsteun, jy het om aan te dui aan die punt mysqlbackup in tyd van die vorige volle of inkrementele rugsteun. Vir gerief, kan jy gebruik maak van die --incremental-basis opsie om outomaties herlei die nodige log volgnommer (LSN) van die metadata gestoor in 'n vorige rugsteun gids of op die bediener. Of jy kan 'n uitdruklike LSN waarde spesifiseer met behulp van die---start LSN opsie, die verskaffing van die beëindiging van LSN mysqlbackup uit 'n vorige volle of inkrementele rugsteun. Om voor te berei die Friends data te herstel, kombineer jy al inkrementele rugsteun met 'n oorspronklike volledige rugsteun. Tipies, jy 'n nuwe volledige rugsteun na 'n aangewese tyd, waarna jy die ouer inkrementele rugsteun data kan weggooi uit te voer. Die skep van inkrementele rugsteun met behulp van slegs die Weer Meld Die --incremental-met-oordoen-log-net dalk 'n paar voordele oor die --incremental opsie bied vir die skep van 'n inkrementele rugsteun: Die veranderings aan InnoDB tafels word bepaal op grond van die inhoud van die InnoDB oordoen teken. Sedert die oordoen log lêers het 'n vaste grootte wat jy vooraf weet, kan dit minder I / O vereis dat die veranderinge van hulle as gelees om die InnoDB table space lêers te scan om die gewysigde bladsye op te spoor, afhangende van die grootte van jou databasis, bedrag van DML aktiwiteit en grootte van die oordoen log files. Sedert die oordoen log lêers op te tree as 'n omsendbrief buffer, met rekords van ouer veranderinge word oor as nuwe DML bedrywighede plaasvind, moet jy 'n nuwe inkrementele rugsteun te neem op 'n voorspelbare skedule bepaal deur die grootte van die log files en die bedrag van die oordoen data gegenereer vir jou werklading. Andersins, kan die oordoen log nie terug ver genoeg reik na al die veranderings sedert die vorige inkrementele rugsteun, in welke geval mysqlbackup vinnig sal bepaal dat dit nie kan voortgaan en sal 'n fout terug te neem. Jou Friends script moet in staat wees om die fout te vang en dan uit te voer 'n inkrementele rugsteun met die --incremental opsie plaas. Om die grootte van die oordoen log bereken, reik die opdrag SHOW VERANDERLIKES SOOS innodb log lêer, en gebaseer op die uitset, vermeerder die innodb log lêer grootte instelling deur die waarde van innodb log lêers in groep. Om die oordoen log grootte op die fisiese vlak te bereken, kyk na die DataDir gids van die MySQL byvoorbeeld en som die groottes van die lêers wat ooreenstem met die patroon IB loglêer. Die InnoDB LSN waarde ooreenstem met die aantal grepe geskryf om die oordoen log. Om die LSN kyk op 'n stadium in die tyd, reik die opdrag SHOW enjin INNODB status en kyk onder die puntelys opskrif. Terwyl die beplanning van jou Friends strategie, teken die LSN waardes van tyd tot tyd en trek die vorige waarde van die huidige een te bereken hoeveel oordoen data gegenereer elke uur, dag, en so aan. Voor MySQL 5.5, was dit algemene praktyk om die oordoen logs redelik klein om 'n lang opstart tyd wanneer die MySQL bediener eerder as gesluit gewoonlik vermoor vermy hou. Met MySQL 5.5 en hoër, word die prestasie van ongeluk herstel aansienlik verbeter, soos beskryf in die optimalisering InnoDB Configuration veranderlikes. sodat jy jou oordoen log lêers groter kan maak as dit help om jou Friends strategie en jou databasis werklading. Hierdie tipe van inkrementele rugsteun is nie so vergewensgesind van te lae---start LSN waardes as die standaard --incremental opsie is. Byvoorbeeld, kan jy nie 'n volledige rugsteun te maak en dan 'n reeks van --incremental-met-oordoen-log-net rugsteun al met behulp van dieselfde --start-LSN waarde. Maak seker dat jy die presiese einde LSN van die vorige rugsteun spesifiseer as die begin LSN van die volgende inkrementele rugsteun nie arbitrêre waardes gebruik. Om te verseker dat die LSN waardes grootgeword het presies tussen opeenvolgende inkrementele rugsteun, word dit aanbeveel dat jy altyd gebruik die --incremental-basis opsie wanneer jy gebruik maak van die --incremental-met-oordoen-log-enigste opsie. Om te oordeel of hierdie tipe van inkrementele rugsteun is praktiese en doeltreffende vir 'n bepaalde MySQL byvoorbeeld: Meet hoe vinnig die data veranderinge binne die InnoDB oordoen log files. Gaan die LSN van tyd tot tyd om te besluit hoeveel oordoen data versamel oor die loop van 'n paar aantal ure of dae. Vergelyk die tempo van redo log opeenhoping met die grootte van die oordoen log files. Gebruik hierdie verhouding om te sien hoe dikwels 'n inkrementele rugsteun te neem, ten einde die waarskynlikheid van die rugsteun by gebreke voorkom as gevolg van die historiese data is nie beskikbaar in die oordoen log. Byvoorbeeld, as jy die vervaardiging van 1GB oordoen log data per dag, en die gekombineerde grootte van jou oordoen log lêers is 7GB, jy sal inkrementele rugsteun meer gereeld te skeduleer as een keer 'n week. Jy kan elke dag of twee uit te voer inkrementele rugsteun, 'n potensiële probleem te vermy wanneer 'n skielike vlaag van updates meer oordoen log data as gewoonlik geproduseer. Maatstaf inkrementele rugsteun keer met behulp van beide die --incremental en --incremental-met-oordoen-teken net-opsies, om te bevestig of die oordoen log Friends tegniek vinniger verrig en met minder oorhoofse as die tradisionele inkrementele rugsteun metode. Die gevolg kan afhang van die grootte van jou data, die bedrag van DML aktiwiteit, en die grootte van jou oordoen log files. Doen jou toets op 'n bediener met 'n realistiese volume data en 'n realistiese werklading. Byvoorbeeld, as jy 'n groot oordoen log lêers, lees hulle in die loop van 'n inkrementele rugsteun kan so lank neem as die lees van die InnoDB data lêers met behulp van die tradisionele inkrementele tegniek. Aan die ander kant, as jou data volume is groot, lees al datalêers die om die paar verander bladsye vind minder doeltreffend as die verwerking van die veel kleiner oordoen log lêers kan wees. Ander oorwegings vir inkrementele rugsteun Die inkrementele rugsteun funksie is hoofsaaklik bedoel vir InnoDB tafels, of nie-InnoDB tafels wat lees-alleen of selde opgedateer. Inkrementele rugsteun spoor veranderinge op die vlak van bladsye in die InnoDB data lêers. in teenstelling met tafel rye elke bladsy wat verander word gerugsteun. So, die ruimte en tyd spaar is nie presies eweredig aan die persentasie van verander InnoDB rye of kolomme. Vir nie-InnoDB lêers, word die hele lêer in 'n inkrementele rugsteun as die lêer het verander sedert die vorige rugsteun, wat beteken dat die besparings vir Friends hulpbronne is minder belangrik wanneer vergelyk met die geval met InnoDB tafels. Jy kan nie uit te voer inkrementele rugsteun met die --compress opsie. Wanneer 'n inkrementele rugsteun wat gebaseer is op 'n rugsteun (volle of inkrementele) gemaak met die --no-locking opsie, gebruik die --skip-binlog opsie om die rugsteun van die binêre log slaan, as binêre log inligting sal wees nie beskikbaar om mysqlbackup in daardie situasie. Voorbeelde van inkrementele rugsteun Hierdie voorbeeld gebruik mysqlbackup om 'n inkrementele rugsteun van 'n MySQL bediener, insluitend alle databasisse en tafels te maak. Ons wys twee alternatiewe, een met behulp van die --incremental-basis opsie en die ander met behulp van die opsie --start-LSN. Met die --incremental-basis opsie, hoef jy nie om tred te hou van LSN waardes tussen een Friends en die volgende hou. In plaas daarvan, kan jy net spesifiseer die rugsteun gids van die vorige rugsteun (óf volle of inkrementele), en mysqlbackup figure uit die beginpunt vir hierdie Friends gebaseer op die metadata van die vorige een. Omdat jy 'n bekende stel gids name nodig, wil jy dalk om hardcoded name gebruik of genereer 'n reeks van name in jou eie Friends script, eerder as die gebruik van die opsie with-tyd stempel. Let daarop dat selfs al is jou laaste Friends 'n enkel-lêer was. jy kan nog steeds gebruik --incremental-basis deur die spesifiseer vir dir: gids pad van die ligging van die tydelike gids wat jy met die --backup-r opsie tydens die volle rugsteun verskaf: As 'n alternatief vir die spesifiseer --incremental-basis rig: gids pad. jy kan vertel mysqlbackup tot die einde toe LSN waarde van die laaste suksesvolle nie-TTS Friends navraag soos opgeteken in die Friends geskiedenis tabel op die bediener met behulp van --incremental-basis geskiedenis: laaste rugsteun (hierdie vereiste dat die laaste rugsteun is gemaak met mysqlbackup verbind na die bediener). Jy kan ook gebruik om die --start LSN opsie spesifiseer waar die inkrementele rugsteun moet begin. Jy moet die LSN rekord van die vorige rugsteun deur mysqlbackup berig aan die einde van die back-up: Die getal is ook opgeneem in die meta / Friends variables. txt lêer in die gids deur --backup-r vermeld tydens die rugsteun. Verskaf dan dat die getal tot mysqlbackup met behulp van die---start LSN opsie. Die inkrementele rugsteun sluit dan al die veranderinge wat na die gespesifiseerde LSN het. Om 'n inkrementele beeld Friends met die --start LSN opsie te skep, gebruik die volgende opdrag spesifiseer met --incremental-Friends-rig die rugsteun gids, wat in hierdie geval, is 'n gids vir die berging van die metadata vir die back-up en sommige tydelike lêers: In die volgende voorbeeld al is, want --backup-beeld nie 'n volledige pad na die beeld-lêer te skep, beeld die inkrementele rugsteun is geskep onder die gids wat deur --incremental-Friends-rig. In die volgende voorbeeld, die --incremental-basis geskiedenis: laaste rugsteun opsie gebruik, gegee wat mysqlbackup haal die LSN van die laaste suksesvolle (nie-TTS) volledige of gedeeltelike Friends van die mysql. backup geskiedenis tafel en voer 'n inkrementele rugsteun baseer op daardie. Gevorderde: Gebruik die volgende opdragte aan inkrementele gids rugsteun te skep, met behulp van die --incremental-basis en die --start LSN opsies: Die handhawing van 'n back-up skedule: Op 'n gereelde skedule bepaal volgens datum of bedrag van databasis aktiwiteit, neem meer inkrementele of differensiële rugsteun. Opsioneel, van tyd tot tyd begin die siklus weer deur 'n volle, ongecomprimeerd of saamgeperste Friends. Tipies, hierdie mylpaal gebeur wanneer jy kan argief en duidelik uit jou oudste Friends data. Oor hoe om jou databasis te herstel met behulp van die inkrementele rugsteun, sien Afdeling 5.1.3, herstel 'n inkrementele rugsteun Implementering NoSync Initializations (en variasies) op SQL Server 2005/8 Ek wil graag 'n kort artikel te doen oor doen nosync initializations vir SQL Server 2005 / 8. Dit is initializations wat Don 'n momentopname t gebruik. Hoekom wil ons graag dinge op hierdie manier (1) Gewoonlik is die rede hiervoor is die grootte van die foto te doen. Dit is veral relevant vir een van my belangrikste kliënte waar ons herhaal om 'n vloot van wêreldwye vaartuie oor smal satelliet skakels. As ons 'n foto gebruik, sou 'n mens besondere publikasie 1 week neem om te inisialiseer. So, die maklikste alternatief is om rits op die databasis Friends en stuur dit oor, pak, te herstel en dan gebruik dit as 'n beginpunt. (2) wat die databasis te verseker dat al die ondersteuning van voorwerpe geneem op dieselfde tyd. Nie al die voorwerpe is in staat om by te voeg as artikels sodat die gebruik van hierdie metode beteken dat ons nie hoef te post-snapshot lêers gebruik en daarom is dit minder onderhoud. (3) kan ons die data reeds by die intekenaar bestaande maar die toepassing van 'n snapashot of 'n databasis te herstel van die uitgewer die stelsel sal breek nie. Dit is duidelik nie 'n aanbevole opstel, maar ek het die twyfelagtige plesier van die werk op so 'n stelsel op 'n bank waar standaard inisialisering is onmoontlik was. As die intekenaar databasis bevat data wat net bestaan op die intekenaar dan sal jy het om dit te gebruik as 'n beginpunt. Nie konvergensie veral in die geval van merge replikasie is iets wat ons probeer om te vermy, maar vreemd in sommige stelsels is dit 'n aanvaarde staat. Let daarop dat in sommige gevalle kan ons ook rits op die foto lêers en gebruik 'n alternatiewe blik plek eerder as die gebruik van 'n databasis Friends egter om 'n back-up is dikwels 'n eenvoudiger metode. Hoe om die intekening by te voeg - die Wizard Wanneer die toevoeging van 'n inskrywing, sal die opsie in die towenaar om te verklaar dat Nee, die intekenaar het reeds die skedule en data wat bestaan het in SQL Server 2000 is vervang deur die skerm hieronder wat is redelik selfverklarend . Ons moet nog steeds die data soos voorheen te kry om die intekenaar, en daar is 'n paar veranderinge wat ons mag nodig wees om te maak om die skema op die intekenaar soos uiteengesit in die onderstaande artikel, maar dit maak ons vir 'n nosync inisialisering. Vir merge replikasie is dit min of meer dieselfde as die vorige metode vir 'n nosync inisialisering en loop die merge agent sal al die ekstra stelsel tafels te genereer, snellers, ens op die intekenaar. Vir transaksionele replikasie is dit nie dieselfde as die nosync inisialisering SQL Server 2000 as in SQL Server 2005/8 ons met behulp van die nuwe replikasie ondersteuning enigste opsie wat hieronder verder verduidelik word. Hoe om die intekening by te voeg - skrifte met behulp skrifte kan ons makliker te sien wat al die beskikbare opsies is en wat dit beteken. SP addsubscription en SP addpushsubscription agent / SP addpullsubscription agent: Om 'n inskrywing in transaksionele replikasie gebruik ons die volgende prosedures voeg. In SP addsubscription daar nou 4 opsies vir sync tipe. Voorheen was daar net 2 opsies: outomatiese (die verstek) en niemand wat gebruik is om 'n nosync inisialisering maak. Dit is nog steeds die geval vir merge replisering in SQL Server 2005/8 so ek sal nie noem dat nie meer nie, maar vir transaksionele ons nou 'n hele paar nuwe opsies wat t uitdruklik in die towenaar sondaars. Om my SQL Server 2000 Artikel parafraseer, het laasgenoemde opsie (geen) wat gebruik word in samewerking met 'n handleiding generasie van replikasie gestoor prosedures wat dan toegepas op elke intekenaar. In SQL Server 2005/8 het ons nou alternatiewe opsies wat: (1) Geen - aanvaar dat die intekenaar het reeds die skedule en aanvanklike data vir gepubliseerde tafels - nou opgeskort is. (Egter SP scriptpublicationcustomprocs is nie gemerk as deprecated vir handleiding gebruik in BOL.) (2) outomatiese (verstek) - outomatiese oordrag van skedule, data, replikasie gestoor prosedures (en snellers waar nodig). (3) replikasie ondersteuning net - Wat beteken die term gemiddelde in hierdie verband is dit die artikel se interne replikasie gestoor prosedures, die replikasie snellers wat ondersteuning opdatering ledegeld en die vereiste replikasie stelsel tafels. So, dit is soos die opsie SQL Server 2000, sonder die kopseer wees om die handleiding skepping en implementering van die gestoor prosedures. Hierdie opsie word aanvaar dat die intekenaar het reeds die skedule en al die aanvanklike data vir gepubliseerde tafels. Hier moet ons baie versigtig wees: - daar moet geen verskil in die data tussen die uitgewer en intekenaar wees. Dit is nie verseker deur die opstel en as DBA ons moet verseker dat dit die geval is. In sommige terminologie hierdie staan bekend as terwyl die data oorgedra word. Dit is duidelik dat as jy werk op 'n stelsel waar daar toegang 24 uur, dit is nie van plan om moontlik wees, sodat opsie (2) of (4) vereis word. - As jy dit die oprigting van die gebruik van 'n back-up, moet die rugsteun geneem word na die publikasie is geskep. Hoekom is dit so krities Omdat die skep van die publikasie maak 'n paar veranderinge aan die skema wat noodsaaklik is vir replisering te werk is. In die besonder, is die identiteit kolomme stel om nie vir die replikasie. - Wees bewus daarvan dat hierdie opstelling nie akkuraat in die GUI weerspieël. Die normale manier van die opstel van artikels is om hulle toe te voeg in die GUI en dan na die artikel eiendomme te wysig. Dit stel ons in staat om te besluit watter regte, snellers, indekse, ens te neem vir 'n bepaalde herhaal artikel. Wysigings daarna om die indeks opstel nie gepropageer bv, maar dit maak voorsiening vir 'n korrelig in die inisialisering proses. In die geval van 'n replikasie ondersteuning enigste opsie, die artikel eienskappe is betekenisloos Jy omleiding hierdie funksie en die neem van die hele databasis. (4) inisialiseer met Friends. Die volledige skedule en aanvanklike data vir gepubliseerde tabelle verkry uit 'n onlangse volle rugsteun van die publikasie databasis. Soos hierbo genoem, moet hierdie Friends geneem word na die publikasie is geskep. Sodra die rugsteun van die publikasie databasis geskep, moet ons verseker dat die intekenaar het toegang tot die rugsteunlêer - óf die Friends is oorgeplaas na die intekenaar of op 'n fileshare dat die intekenaar kan lees gestel. Die ligging van die Friends en media tipe vir die back-up is wat deur 2 nuwe parameters van SP addsubscription. backupdevicename en backupdevicetype. Op hierdie stadium sal ek daarop dat jy sal moet 3 dinge te doen: (a) te verwyder oortollige voorwerpe en tafels. Daar is geen punt stapels tot die databasis van die kliënt met niks wat t daar wouldn wees is jy 'n outomatiese inisialisering gedoen het. Dit sal die bespoediging van die rugsteun en te verduidelik aan ander administrateurs wat die intekenaar gebruik word vir. (B) vervang tyd stempel kolomme met binêre (8) kolomme. Jy sal moet 'n tydelike hou tabel gebruik om dit te bereik. (C) onthou dat die rugsteun sluit alle data, selfs al ry of kolom filters word vermeld op 'n tafel - so 'n paar kolomme moet dalk te laat val. Hoe werk, en hoe om slaggate te vermy By die gebruik van, SP addsubscription intern noem RESTORE HEADERONLY om die laaste LSN onttrek van Friends om gebruik te word as die beginpunt van die nuwe inskrywing. 'N daaropvolgende vergelyking getref word om die XACT seqno waarde in distribution..MSrepl bevele. en die nodige opdragte oorgedra. Om te verseker dat al die nodige opdragte werklik bestaan in die MSrepl beveel tafel moet ons die Friends herstel voordat die behoud tydperk verkry is en die verspreiding opruim agent verwyder die rye. BOL beveel aan dat ons die verspreiding opruim agent gedurende hierdie tydperk te skakel om te verseker dat dit alles glad verloop. As jy hierdie fout, sal jy die volgende boodskap: Msg 21397, Vlak 16, Staat 1, Prosedure SP MSsetupnosyncsubwithlsnatdist, Line 213 Die transaksies wat nodig is vir die synchroniseren die nosync inskrywing gemaak op grond van die bepaalde Friends is beskikbaar by die verspreider. Weer die operasie weer met 'n meer up-to-date log, ewenaar, of volle databasis Friends. Die kliënt laat val. Toevoeging van nuwe tafels As jy 'n nuwe artikel by te voeg tot 'n publikasie wat 'n intekenaar ingestel as replikasie ondersteuning net jy het 'n bietjie versigtig wees. Vir 'n normale (verstek) inskrywing sal ons die foto agent om die skrifte vir die nuwe artikel te skep hardloop en dit sou dan toegepas word op die intekenaar. In hierdie geval is dit anders. Na die toevoeging van voortplanting die nuwe artikel, sal daar 'n boodskap in die verspreiding agent geskiedenis sê Toegepaste die foto om die intekenaar wees. Maar as jy kyk op die intekenaar jy sal nie so 'n tafel sien. Wat is geskep op die intekenaar tydens hierdie proses is die interne gestoor prosedures om opdragte van toepassing op die nuwe tabel. Skepping van die werklike tafel en die data op die intekenaar is aan jou. So, maak seker dat jy iets soos BVIP gebruik om die tafel en die oordrag van data. Maak seker dat die identiteit kolomme is ingestel om NIE VIR replikasie en enige verwante voorwerpe daar het ook - soos nie-gegroepeer indekse en snellers. Werklik wat jy nodig het om dit te doen voordat hulle aansoek doen om die nuwe artikel. In wese al beteken dit dat die stelsel moet quiesced terwyl dit gebeur, sodat ons don t verloor enige data. Daarom kan ons sê dat die aanvanklike rede waarom ons hierdie metode gebruik breek wanneer ons voeg artikels Gevolgtrekkings Hopelik sal hierdie artikel jou help om voordeel te trek uit die nuttige nuwe opsies in die oprigting van 'n nosync inisialisering. Hierdie opsie was nog altyd betrokke party nodig script vereistes, en dit kan nooit heeltemal gedoen word met behulp van die GUI. Nou met SQL Server 2005/8 is dit selfs meer so, maar die bykomende opsies te bied 'n noodsaaklike alternatief vir outomatiese initializations. Danksy Nigel Maneffa vir daarop te wys n paar verbeteringe op hierdie artikel. Differensiële gene en transkripsie uitdrukking ontleding van RNA-ev eksperimente met tophat en Cufflinks Abstract Onlangse vooruitgang in hoë-deurset cDNA volgorde (RNA-ev) kan nuwe gene en Splice variante openbaar en kwantifiseer uitdrukking genoom-wye in 'n enkele toets. Die volume en kompleksiteit van data van RNA-ev eksperimente noodsaak skaalbare, vinnig en wiskundig beginselvaste analise sagteware. Tophat en Cufflinks is gratis, open-source sagteware gereedskap vir ontdekking van gene en omvattende uitdrukking ontleding van 'n hoë-deurset mRNA volgorde (RNA-ev) data. Saam, hulle toelaat dat bioloë om nuwe gene en nuwe Splice variante van bekendes te identifiseer, asook vergelyk gene en transkripsie uitdrukking onder twee of meer voorwaardes. Hierdie protokol beskryf in detail hoe om tophat en Cufflinks gebruik om sodanige ontledings uit te voer. Dit dek ook 'n paar bykomende gereedskap en utilities wat steun in die bestuur van data, insluitend cummerbund, 'n instrument vir die visualisering van RNA-ev analise resultate. Hoewel die prosedure veronderstel basiese informatika vaardighede, hierdie gereedskap neem min of geen agtergrond met RNA-ev ontleding en is bedoel vir beide beginners en kundiges. Die protokol begin met rou volgorde lees en lewer 'n transkriptoom vergadering, lyste van differensieel uitgedruk en gereguleer gene en transkripsies, en publikasie-gehalte visualisaties van analise resultate. uitvoering van die protokol is tyd hang af van die volume van die transkriptoom volgorde data en beskikbaar rekenaar hulpbronne, maar neem minder as 1 d van die rekenaar tyd vir 'n tipiese eksperimente en 1 uur van hands-on tyd. INLEIDING Hoë-deurset mRNA volgorde (RNA-ev) bied die vermoë om nuwe gene en transkripsies te ontdek en te meet transkripsie uitdrukking in 'n enkele toets 1 huidige instrumente genereer meer as 500 gigabases in 'n enkele lopie. Daarbenewens is volgordebepaling koste eksponensieel vermindering, die opening van die deur na bekostigbare persoonlike volgorde en nooi vergelykings met kommoditeit rekenaar en die impak daarvan op die samelewing 4. Hoewel die volume van data van RNA-ev eksperimente is dikwels baie swaar, kan dit enorme insig te verskaf. Net soos cDNA volgorde met Sanger sequencers drasties uitgebrei ons katalogus van bekende menslike gene 5. RNA-ev onthul die volle repertoire van alternatiewe Splice isoforme in ons transkriptoom en werp lig op die skaarsste en mees sel en konteks-spesifieke transkripsies 6. Verder omdat die aantal lui afkomstig van 'n RNA transkripsie is 'n funksie van die transkripsie se oorvloed, kan lees digtheid gebruik word om transkripsie 7, 8 en gene 2, 3, 9 meet, 10 uitdrukking met vergelykbare of beter akkuraatheid te uitdrukking Arrays 1, 11. RNA-ev eksperimente moet ontleed met robuuste, doeltreffende en statisties beginselvaste algoritmes. Gelukkig het die bioinformatika gemeenskap hard aan die werk was die ontwikkeling van wiskunde, statistiek en rekenaarwetenskap vir RNA-ev en die bou van hierdie idees in sagteware gereedskap (vir 'n onlangse hersiening van analise konsepte en sagteware pakkette sien Garber et al. 12). RNA-ev analise-instrumente in die algemeen val in drie kategorieë: (i) dié vir lees belyning (ii) dié vir transkripsie vergadering of genoom annotasie en (iii) wat vir transkripsie en gene kwantifisering. Ons het twee gewilde instrumente wat saam al drie rolle, sowel as 'n nuwer hulpmiddel vir die visualisering van analise resultate dien ontwikkel. Tophat 13 (tophat. cbcb. umd. edu/) laat lui om die genoom en ontdek transkripsie Splice webwerwe. Hierdie roetes gebruik word tydens stroomaf analise op verskeie maniere. Manchetknopen 8 (cufflinks. cbcb. umd. edu/) gebruik hierdie kaart teen die genoom te vergader die lees in transkripsies. Cuffdiff, 'n deel van die Cufflinks pakket, neem die lyn lui uit twee of meer voorwaardes en verslae gene en transkripsies wat differensieel uitgedruk met behulp van 'n streng statistiese analise. Hierdie gereedskap is besig om wye aanvaarding en gebruik is in 'n aantal onlangse hoë-resolusie transkriptoom bestudeer 14 17. cummerbund lewer Cuffdiff uitset in publikasie-gereed figure en erwe. Figuur 1 toon die sagteware wat gebruik word in hierdie protokol en beklemtoon die belangrikste funksies van elke instrument. Alle gereedskap gebruik word in die protokol is ten volle gedokumenteer op die web, aktief in stand gehou word deur 'n span van die ontwikkelaars en goed aanvaar data stoor en oordrag standaarde aan te neem. Sagteware komponente wat in hierdie protokol. Bowtie 33 vorm die algoritmiese kern van tophat, wat miljoene in lyn van RNA-ev lees om die genoom per CPU uur. Tophat s Lees roetes is saamgestel deur Cufflinks en sy verwante nutsprogram te produseer. Beperkings van die protokol en sagteware tophat en Cufflinks nie aan te spreek alle aansoeke van RNA-ev, of is hulle die enigste gereedskap vir RNA-ev ontleding. In die besonder, tophat en Cufflinks vereis dat 'n sekere volgorde genoom (sien hieronder vir verwysings na instrumente wat sonder 'n verwysing genoom kan gebruik word). Hierdie protokol veronderstel ook dat RNA-ev uitgevoer met óf Illumina of soliede volgorde masjiene. Ander volgorde tegnologie soos 454 of die klassieke kapillêre elektroforese benadering kan gebruik word vir grootskaalse cDNA volgorde, maar ontleding van sodanige data is aansienlik verskil van die benadering wat hier gebruik word. Tophat en Cufflinks is beide bedryf deur die UNIX dop. Geen grafiese gebruikerskoppelvlak is ingesluit. Daar is egter nou kommersiële produkte en open-source koppelvlakke om hierdie en ander RNA-ev analise-instrumente. Byvoorbeeld, die Melkweg Projek 18 gebruik 'n web koppelvlak tot die berekening van hulpbronne wolk om opdrag-lyn gedryf gereedskap soos tophat en Cufflinks om gebruikers te bring sonder UNIX vaardighede deur die web en die rekenaar wolk. Alternatiewe analise pakkette tophat en Cufflinks bied 'n volledige RNA-ev workflow, maar daar is ander RNA-ev analise pakkette wat gebruik kan word in plaas van, of in kombinasie met die gereedskap in hierdie protokol. Baie alternatiewe lees-aanpassing programme 19 28 analise. Omdat baie van hierdie gereedskap te werk op soortgelyke wyse geformateer data lêers, kan hulle gebruik word in plaas van of bykomend tot die gereedskap wat hier gebruik word. Byvoorbeeld, met eenvoudige naprosessering skrifte, kan 'n mens GSNAP 19 Lees roetes bied om Cufflinks, of gebruik 'n Skrif 22 transkriptoom heropbou in plaas van 'n Cufflinks een voor differensiële uitdrukking ontleding. Maar so 'n aanpassing is buite die bestek van hierdie protokol, en ons ontmoedig beginner RNA-ev gebruikers van die verandering van die hier uiteengesit protokol. Hierdie protokol is geskik vir RNA-ev eksperimente op organismes met opeenvolgende verwysing genome. Gebruikers werk sonder 'n sekere volgorde genoom maar wat belangstel in ontdekking van gene is in ag moet neem presterende de novo transkriptoom vergadering met behulp van een van verskeie instrumente soos Drie-eenheid 29. Trans-afgrond 30 of Oases (ebi. ac. uk/ zerbino / oases /). Gebruikers wat uitdrukking analise met 'n de novo transkriptoom vergadering mag wens om te oorweeg RSEM 10 of IsoEM 25. Vir 'n oorsig van hierdie instrumente (insluitend tophat en Cufflinks) lesers kan wens om die studie te sien deur Garber et al. 12. wat hul vergelykende voordele en nadele en die teoretiese oorwegings wat hul ontwerp inlig beskryf. Oorsig van die protokol Hoewel RNA-ev eksperimente baie doeleindes dien, ons beskryf 'n workflow wat daarop gemik is om die transkriptoom profiele van twee of meer biologiese toestande, soos 'n wilde-tipe teenoor mutant of beheer versus uitklop eksperimente te vergelyk. Vir eenvoud, ons aanvaar dat die eksperiment vergelyk slegs twee biologiese toestande, hoewel die sagteware is ontwerp om baie meer te ondersteun, insluitend time-natuurlik eksperimente. Hierdie protokol begin met rou RNA-ev lees en sluit af met die publikasie-gereed visualisering van die analise. Figuur 2 dui op die belangrikste stappe van die protokol. Eerstens, lees vir elke toestand is gekarteer om die verwysing genoom met tophat. Baie RNA-ev gebruikers is ook geïnteresseerd in gene of Splice variant ontdekking, en die versuim om so kyk vir nuwe transkripsies kan vooroordeel uitdrukking skattings en verminder akkuraatheid 8. Ons sluit transkripsie vergadering met Cufflinks as 'n stap in die workflow (sien kassie 1 vir 'n workflow wat gene en transkripsie ontdekking) spring. Na die hardloop tophat, is die gevolg belyning lêers aan Cufflinks 'n transkriptoom vergadering vir elke toestand te genereer. Hierdie gemeentes word dan saamgevoeg saam met behulp van die Cuffmerge nut, wat deel uitmaak van die Cufflinks pakket. Dit saamgesmelte vergadering bied 'n eenvormige grondslag vir die berekening van gene en transkripsie uitdrukking in elke toestand. Die lees en die saamgesmelte vergadering gevoer om Cuffdiff, wat uitdrukking vlakke bereken en toets die statistiese betekenisvolheid van waargenome veranderinge. Cuffdiff voer ook 'n bykomende laag van differensiële analise. Deur die groepering transkripsies in biologies betekenisvolle groepe (soos transkripsies wat dieselfde transkripsie begin werf (TOVS) te deel), Cuffdiff identifiseer gene wat differensieel gereguleer by die transkripsionele of post-transkripsionele vlak.
No comments:
Post a Comment