Sabato e domenica [...] ho implementato una replica merge, sembrava facile facile e si è rilevata densa di complessità, la replica non si smentisce mai .

La situazione comprendeva un server [A] con IP pubblico statico e un server [B] remoto senza IP statico. Le strade possibili erano quindi:

- Pubblicatore su A e sottoscrittore pull su B
- Pubblicatore su B e sottoscrittore push su A

Per vari motivi preferivo che pubblicasse A, il server principale, e le strade erano di nuovo [almeno] 2:

- VPN tra A e B
- Replica anonima via internet con la 1433 di A aperta.

La seconda scelta è deprecabile per motivi di sicurezza ma è altrettanto vero che non esistono buchi noti per cui l'apertura della porta dovrebbe permettere accessi indesiderati, ovviamente sono richiesti un paio di occhi e orecchie aggiuntivi, una buona password per sa non forzabile brute force e un minimo di coraggio.

Nel mio caso reale la porta non è la 1433 ma è stata modificata per varie ragioni, non ultimo il problema sicurezza. Questo fatto rende subito la replica più macchinosa poichè la registrazione di A su B con il classico nome <IP,Porta> permette la creazione della replica senza errori tranne cominciare a fare i capricci alla prima sincronizzazione. Il primo passo consiste quindi nel ricordarsi che esiste l'utility cliconfg.exe [Configurazione rete client] e che tale utility permette tra le altre cose di definire alias specificando anche la porta di ascolto e quindi procedere definendo in B un alias di <IP di A,porta> con il nome esatto del server A.

Fatto ciò la replica si tira insieme senza troppi accidenti a parte la questione snapshot. Se i due server non condividono la rete, su quale cartella si dovrebbero scambiare gli snapshot? SQL Server 2000 permette di pubblicare gli snapshot in una cartella a cui il sottoscrittore accede via ftp. Purtroppo il pubblicatore non può [per quel che ne so] pubblicare lo snapshot su ftp ma solo salvare i file in una cartella di rete che risulta poi avere accesso ftp dall'esterno, quindi:

- O il pubblicatore è server web ftp
- O il pubblicatore è in rete locale con un server web ftp

Purtroppo la mia situazione era lievemente diversa, in rete c'è un server web ma con Linux e senza Samba. Ho deciso quindi di spostare manualmente gli snapshot sul server web via ftp lasciando che SQL restasse convinto che la cartella su cui esegue gli snapshot sia pubblicata via ftp. Il sottoscrittore recupera dal pubblicatore le credenziali di accesso e ci prova, qualcosa fa ma fallisce. Non ho avuto modo di approfondire la cosa ma mi pare di capire che le chiamate ftp del sottoscrittore non piacciano troppo al server Linux. Appena avrò un attimo proverò a verificare.

Quindi anche lo spostamento degli snapshot dal server web al sottoscrittore è stato fatto manualmente e il sottoscrittore è stato impostato per la lettura degli snapshot su una cartella locale.

Alla fine tutto è andato bene, ho replicato manualmente la sovrastruttura di viste, funzioni e stored [io replico sempre e solo le tabelle con SQL 2000, con SQL 2005 l'introduzione degli script per operazioni DDL dovrebbe avere migliorato enormemente il supporto per la replica dei metadati]. Faccio qualche prova e scopro con una discreta frustrazione che gli user data types erano stati replicati come tipi primitivi.

Quindi ho dovuto rifare tutto il processo senza dimenticare che per, qualche motivo, di default i tipi dati utente vengono convertiti nei rispettivi tipi dato primitivi. Questa storia dei default mi ha ricordato anche che, per qualche altro oscuro motivo, le sottoscrizioni scadono dopo 14 giorni di inattività e sono corso a modificare il parametrino.

Rigenerati gli snapshot, spostati su ftp, scaricati sul sottoscrittore, replicati gli schemi di viste e funzioni e storeeds tutto ha preso finalmente a girare a regime.

marc.