Domanda

Ho una buona idea di cosa può fare la replica di MySQL. Mi chiedo quali altri database supportano la replica e come si confrontano con MySQL e altri?

Alcune domande che vorrei avere sono:

  1. La replica è integrata o un componente aggiuntivo / plug-in?
  2. Come funziona la replica (di alto livello)? MySQL fornisce la replica basata su istruzioni (e la replica basata su righe in 5.1). Sono interessato a come confrontare altri database. Cosa viene spedito via cavo? Come vengono applicate le modifiche alle repliche?
  3. È facile verificare la coerenza tra master e slave?
  4. Quanto è facile ripristinare una replica non riuscita in sincronia con il master?
  5. Performance? Una cosa che odio della replica di MySQL è che è a thread singolo e le repliche hanno spesso problemi a tenere il passo, poiché il master può eseguire molti aggiornamenti in parallelo, ma le repliche devono eseguirli in serie. Ci sono dei gotcha come questo in altri database?
  6. Altre funzionalità interessanti ...
È stato utile?

Soluzione

La replica di MySQL è debole in quanto è necessario sacrificare altre funzionalità per ottenere il supporto completo master / master (a causa della restrizione sui back-end supportati).

La replica di PostgreSQL è debole in quanto è supportato solo il master / standby incorporato (usando il log shipping); soluzioni più potenti (come Slony o Londiste) richiedono funzionalità aggiuntive. I segmenti del registro di archivio vengono spediti tramite cavo, che sono gli stessi record utilizzati per assicurarsi che un database autonomo sia funzionante, in stato coerente all'avvio non pulito. Questo è quello che sto usando attualmente, e abbiamo la risincronizzazione (e l'installazione e altre funzionalità) completamente automatizzata. Nessuno di questi approcci è completamente sincrono. A partire da PostgreSQL 8.5 verrà integrato un supporto più completo. La distribuzione dei log non consente ai database di uscire dalla sincronizzazione, quindi non è necessario che i processi testino lo stato sincronizzato; riportare i due database in sincronia comporta l'impostazione del flag di backup sul master, la risincronizzazione con lo slave (con il database ancora in esecuzione; questo è sicuro) e la disattivazione del flag di backup (e il riavvio del processo slave) con i log di archivio generati durante il processo di backup disponibile; il mio negozio ha automatizzato questo processo (come tutte le altre attività amministrative). Le prestazioni non sono un problema, dal momento che il master deve comunque riprodurre internamente i segmenti di registro oltre a svolgere altre attività; quindi, gli schiavi saranno sempre sotto carico meno del master.

Il RAC di Oracle (che non è propriamente replica, in quanto esiste un solo back-end di archiviazione - ma hai più frontend che condividono il carico e puoi creare ridondanza in quel back-end di archiviazione condiviso, quindi è degno di menzione qui) è un approccio multi-master molto più completo rispetto ad altre soluzioni, ma è estremamente costoso. I contenuti del database non vengono "spediti via cavo"; invece, vengono archiviati nel back-end condiviso, a cui possono accedere tutti i sistemi coinvolti. Poiché esiste un solo backend, i sistemi non possono uscire dalla sincronizzazione.

Continuing offre una soluzione di terze parti che esegue una replica completamente sincrona a livello di istruzione con supporto per tutti e tre i database di cui sopra; tuttavia, la versione commercialmente supportata del loro prodotto non è particolarmente economica (sebbene notevolmente meno costosa. L'ultima volta che l'ho amministrata, la soluzione di Continuent ha richiesto un intervento manuale per riportare un cluster in sincronia.

Altri suggerimenti

Ho una certa esperienza con MS-SQL 2005 (editore) e SQLEXPRESS (abbonati) con replica di unione oltremare. Ecco i miei commenti:

1 - La replica è integrata o un componente aggiuntivo / plug-in?

Integrato

2 - Come funziona la replica     (Di alto livello)?

Diversi modi per replicare, dall'istantanea (che fornisce dati statici a livello di abbonato) alla replica transazionale (ogni istruzione INSERT / DELETE / UPDATE viene eseguita su tutti i server). Unisci replica replica solo le modifiche finali (gli AGGIORNAMENTI successivi sullo stesso record verranno eseguiti contemporaneamente durante la replica).

3 - È facile verificare la coerenza tra master e slave?

Qualcosa che non ho mai fatto ...

4 - Quanto è facile riavviare una replica fallita in sincronia con il master?

Il processo di risincronizzazione di base è solo un doppio clic .... Ma se hai 4Go di dati da reinizializzare su una connessione a 64 Kb, sarà un processo lungo a meno che non lo personalizzi.

5 - Prestazioni?

Bene ... Ovviamente avrai un collo di bottiglia da qualche parte, essendo le prestazioni della tua connessione, il volume di dati o infine le prestazioni del tuo server. Nella mia configurazione, gli utenti scrivono solo agli abbonati, che si replicano tutti con il database principale = editore. Questo server non viene quindi richiesto dagli utenti finali e la sua CPU è strettamente dedicata alla replica dei dati (a più server) e al backup. Gli abbonati sono dedicati ai clienti e una replica (all'editore), il che fornisce un risultato molto interessante in termini di disponibilità dei dati per gli utenti finali. Le repliche tra editore e abbonati possono essere lanciate insieme.

6 - Qualsiasi altra caratteristica interessante ...

È possibile, con qualche anticipazione, continuare a sviluppare il database senza nemmeno arrestare il processo di replica .... tabelle (in modo indiretto), campi e regole possono essere aggiunti e replicati ai tuoi abbonati.

Le configurazioni con un editore principale e più soggetti interessati possono essere MOLTO economiche (se confrontate con alcune altre ...), poiché è possibile utilizzare lo SQLEXPRESS gratuito sul lato del destinatario, anche quando si eseguono merge o repliche transazionali

Basta aggiungere alle opzioni con SQL Server (in particolare SQL 2008, che ora ha le funzionalità di rilevamento delle modifiche). Qualcosa da considerare è il Sync Framework di Microsoft. Ci sono alcune opzioni lì, dall'architettura di base hub-and-speak che è eccezionale se hai un singolo server centrale e client a volte connessi, fino alla sincronizzazione peer-to-peer che ti dà la possibilità di fare molto più avanzato sincronizzazione con più database "master".

Il motivo per cui potresti voler considerare questo invece della replica tradizionale è che hai molto più controllo dal codice, ad esempio puoi ottenere eventi durante l'avanzamento della sincronizzazione per Aggiorna / Aggiorna, Aggiorna / Elimina, Elimina / Aggiorna, Inserisci / Inserisci i conflitti e decidi come risolverli in base alla logica aziendale e, se necessario, memorizza i perdenti dei dati del conflitto da qualche parte per l'elaborazione manuale o automatica. Dai un'occhiata a questa guida per aiutarti a decidere cosa è possibile con il diversi metodi di replica e / o sincronizzazione.

Per i programmatori appassionati, Sync Framework è abbastanza aperto da consentire ai client di connettersi tramite WCF al servizio WCF che può astrarre qualsiasi archivio di dati back-end (ho sentito che alcune persone stanno sperimentando l'utilizzo di Oracle come back-end) .

Il mio team è appena uscito con un grande progetto che coinvolge più database SQL Express sincronizzando sottoinsiemi di dati da un database SQL Server centrale tramite WAN e Internet (connessione remota lenta in alcuni casi) con grande successo.

MS SQL 2005 Standard Edition e versioni successive hanno eccellenti capacità e strumenti di replica. Dai un'occhiata a:

http://msdn.microsoft.com/ it-it / library / ms151198 (SQL.90) .aspx

È abbastanza capace. Puoi anche utilizzare SQL Server Express come abbonato di sola lettura.

Ci sono molte cose diverse che il database chiama la replica. In realtà non tutti implicano la replica e quelli che funzionano in modi molto diversi. Alcuni database supportano diversi tipi.

MySQL supporta la replica asincrona, il che è molto buono per alcune cose. Tuttavia, ci sono punti deboli. La replica basata su istruzioni non è la stessa di quella che fanno la maggior parte degli altri database e non sempre comporta il comportamento previsto. La replica basata su righe è supportata solo da una versione non pronta per la produzione (ma è più coerente con il modo in cui lo fanno altri database).

Ogni database ha una propria opinione sulla replica, alcuni implicano altri strumenti che si collegano.

Un po 'fuori tema ma potresti voler controllare Maatkit alla ricerca di strumenti che possano aiutare con la replica di MySQL.

Tutti i principali database commerciali hanno una replica decente, ma alcuni sono più decenti di altri. IBM Informix Dynamic Server (versione 11 e successive) è particolarmente buono. In realtà ha due sistemi: uno per l'alta disponibilità (HDR - replica dei dati ad alta disponibilità) e l'altro per la distribuzione dei dati (ER - replica aziendale). E anche le funzionalità di Mach 11 (RSS - secondario standalone remoto e SDS - secondario disco condiviso) sono eccellenti, doppiamente in 11.50 dove puoi scrivere sul primario o sul secondario di una coppia HDR.

( Informativa completa: lavoro su Informix softare. )

Non l'ho provato da solo, ma potresti anche voler esaminare OpenBaseSQL, che sembra avere una replica integrata semplice da usare.

Un altro modo di procedere è eseguire in un ambiente virtualizzato. Ho pensato che i dati di questo articolo sul blog fossero interessanti

http://chucksblog.typepad.com/chucks_blog/2008 /09/enterprise-apps.html

Proviene da un dirigente EMC, quindi ovviamente non è indipendente, ma l'esperimento dovrebbe essere riproducibile

Ecco i dati specifici per Oracle

http: / /oraclestorageguy.typepad.com/oraclestorageguy/2008/09/to-rac-or-not-to-rac-reprise.html

Modifica: se si esegue virtualizzato, ci sono modi per replicare qualsiasi cosa

http://chucksblog.typepad.com/chucks_blog /2008/05/vmwares-srm-cha.html

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top