Veritaban\u0131 ge\u00e7i\u015fleri kabus olmak zorunda de\u011fil! Mevcut sisteminizi etkilemeden, veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc koruyarak ve kesintisiz hizmetle iki veritaban\u0131 aras\u0131nda sorunsuz ge\u00e7i\u015fin s\u0131rlar\u0131n\u0131 bu makalede ke\u015ffedin.<\/p>\n
Modern teknoloji d\u00fcnyas\u0131nda, \u015firketler s\u00fcrekli olarak de\u011fi\u015fen gereksinimlere ayak uydurmak zorundad\u0131r. Bu de\u011fi\u015fimlerin ba\u015f\u0131nda da altyap\u0131 ve veritaban\u0131 teknolojileri gelmektedir. Bir\u00e7ok organizasyon, eski veya yetersiz kalm\u0131\u015f bir veritaban\u0131 sisteminden daha modern, daha \u00f6l\u00e7eklenebilir veya daha maliyet etkin bir \u00e7\u00f6z\u00fcme ge\u00e7i\u015f yapma ihtiyac\u0131 hisseder. \u00d6rne\u011fin, lisans maliyetlerini d\u00fc\u015f\u00fcrmek, bulut tabanl\u0131 bir mimariye ge\u00e7i\u015f yapmak, NoSQL \u00e7\u00f6z\u00fcmlerle daha esnek bir veri yap\u0131s\u0131 olu\u015fturmak veya mevcut sistemin performans darbo\u011fazlar\u0131n\u0131 a\u015fmak gibi nedenlerle veritaban\u0131 ge\u00e7i\u015fi g\u00fcndeme gelebilir.<\/p>\n
Ancak, “veritaban\u0131 ge\u00e7i\u015fi” kelimesi bile pek \u00e7ok IT uzman\u0131n\u0131n ka\u015flar\u0131n\u0131 \u00e7atmas\u0131na, hatta uykular\u0131n\u0131n ka\u00e7mas\u0131na neden olabilir. Bunun temel nedeni, bu t\u00fcr operasyonlar\u0131n beraberinde getirdi\u011fi ciddi risklerdir. Veri kayb\u0131, sistemin saatlerce hatta g\u00fcnlerce kapal\u0131 kalmas\u0131, uygulama uyumsuzluklar\u0131, performans d\u00fc\u015f\u00fc\u015fleri ve beklenmedik hatalar, bir ge\u00e7i\u015f projesini kolayca bir kabusa d\u00f6n\u00fc\u015ft\u00fcrebilir. \u00d6zellikle canl\u0131 sistemlerde, her saniyenin ve her veri par\u00e7as\u0131n\u0131n kritik oldu\u011fu i\u015f ortamlar\u0131nda, en ufak bir aksakl\u0131k bile milyonlarca dolarl\u0131k kay\u0131plara ve m\u00fc\u015fteri memnuniyetsizli\u011fine yol a\u00e7abilir. Bu nedenle, bir veritaban\u0131 ta\u015f\u0131ma projesi, detayl\u0131 planlama, titiz uygulama ve kapsaml\u0131 test s\u00fcre\u00e7leri gerektiren, y\u00fcksek riskli bir operasyon olarak g\u00f6r\u00fcl\u00fcr.<\/p>\n
Peki, bu kadar b\u00fcy\u00fck riskler bar\u0131nd\u0131ran bir s\u00fcreci “s\u0131f\u0131r drama” ile atlatmak ger\u00e7ekten m\u00fcmk\u00fcn m\u00fcd\u00fcr? Kesinlikle evet! Do\u011fru yakla\u015f\u0131mlar, modern teknikler ve sa\u011flam bir stratejiyle, veritaban\u0131 ge\u00e7i\u015finizi m\u00fcmk\u00fcn olan en az stresle ve en y\u00fcksek ba\u015far\u0131 oran\u0131yla tamamlayabilirsiniz. Anahtar, aceleci davranmak yerine her ad\u0131m\u0131 \u00f6nceden d\u00fc\u015f\u00fcnmek, potansiyel sorunlar\u0131 \u00f6ng\u00f6rmek ve bunlara kar\u015f\u0131 proaktif \u00e7\u00f6z\u00fcmler geli\u015ftirmektir. Bu makale boyunca, bu “drama yok” felsefesinin temel prensiplerini ve uygulamalar\u0131n\u0131 detayl\u0131 bir \u015fekilde inceleyece\u011fiz. Ba\u015far\u0131l\u0131 bir veritaban\u0131 migrasyonu i\u00e7in gereken her \u015feyi ad\u0131m ad\u0131m \u00f6\u011frenecek, b\u00f6ylece siz de kendi projelerinizde benzer bir sakinlik ve g\u00fcvenle ilerleyebileceksiniz.<\/p>\n
Bir veritaban\u0131 ge\u00e7i\u015finin ba\u015far\u0131s\u0131, teknik uygulamadan \u00e7ok daha \u00f6nce, do\u011fru planlama ve strateji belirleme a\u015famas\u0131nda \u015fekillenir. Asl\u0131nda, sakin bir migrasyonun temel ta\u015flar\u0131, detayl\u0131 bir yol haritas\u0131 \u00e7\u0131karmaktan ve olas\u0131 t\u00fcm senaryolar\u0131 \u00f6ng\u00f6rmekten ge\u00e7er. Bu b\u00f6l\u00fcm, ge\u00e7i\u015f s\u00fcrecinin olmazsa olmaz ad\u0131mlar\u0131n\u0131 ve kritik karar noktalar\u0131n\u0131 ele alacakt\u0131r.<\/p>\n
Her \u015feyden \u00f6nce, “Neden ge\u00e7i\u015f yap\u0131yoruz?” sorusunun cevab\u0131 netle\u015ftirilmelidir. Performans art\u0131\u015f\u0131, maliyet d\u00fc\u015f\u00fcrme, yeni \u00f6zellikler, bulut uyumlulu\u011fu gibi temel bir hedef belirlenmeli ve bu hedef do\u011frultusunda kaynak (eski) ve hedef (yeni) veritaban\u0131 sistemleri dikkatle se\u00e7ilmelidir. Bu se\u00e7im, sadece teknik \u00f6zelliklere de\u011fil, ayn\u0131 zamanda ekibin yetkinli\u011fine, ekosistem deste\u011fine ve gelecekteki b\u00fcy\u00fcme planlar\u0131na da uygun olmal\u0131d\u0131r. Ard\u0131ndan, mevcut veritaban\u0131n\u0131n \u015femas\u0131, veri tipleri, indeksleri, sakl\u0131 yordamlar\u0131 ve tetikleyicileri detayl\u0131ca analiz edilmeli ve hedef veritaban\u0131na nas\u0131l d\u00f6n\u00fc\u015ft\u00fcr\u00fclece\u011fi planlanmal\u0131d\u0131r. \u00d6zellikle veri modelleme farkl\u0131l\u0131klar\u0131, karma\u015f\u0131k sorgular ve i\u015f mant\u0131\u011f\u0131 i\u00e7eren SQL kodlar\u0131n\u0131n adaptasyonu \u00f6nemli bir s\u00fcre\u00e7tir. Bu a\u015famada, veri temizli\u011fi (data cleansing) ve normalizasyon gibi ad\u0131mlar da d\u00fc\u015f\u00fcn\u00fclmelidir; zira temiz ve d\u00fczenli veri, ge\u00e7i\u015f s\u00fcrecini b\u00fcy\u00fck \u00f6l\u00e7\u00fcde kolayla\u015ft\u0131racakt\u0131r.<\/p>\n
Risk analizi, ge\u00e7i\u015f s\u00fcrecinin en kritik ad\u0131mlar\u0131ndan biridir. Potansiyel veri kayb\u0131 riskleri, g\u00fcvenlik a\u00e7\u0131klar\u0131, performans darbo\u011fazlar\u0131 ve uygulama uyumsuzluklar\u0131 belirlenmelidir. Her risk i\u00e7in bir hafifletme plan\u0131 (mitigation plan) ve bir acil durum plan\u0131 (contingency plan) olu\u015fturulmal\u0131d\u0131r. Yedekleme ve geri d\u00f6n\u00fc\u015f (rollback) stratejileri bu planlar\u0131n olmazsa olmaz par\u00e7alar\u0131d\u0131r. Hangi s\u0131kl\u0131kla yedekleme yap\u0131laca\u011f\u0131, yedeklerin nerede saklanaca\u011f\u0131 ve bir sorun an\u0131nda eski sisteme nas\u0131l geri d\u00f6n\u00fclece\u011fi ad\u0131m ad\u0131m tan\u0131mlanmal\u0131d\u0131r. Son olarak, ge\u00e7i\u015f ekibi olu\u015fturulmal\u0131, her \u00fcyeye belirli sorumluluklar atanmal\u0131 ve net bir ileti\u015fim plan\u0131 belirlenmelidir. Bu sayede, t\u00fcm payda\u015flar s\u00fcre\u00e7 hakk\u0131nda bilgilendirilecek ve olas\u0131 kriz anlar\u0131nda h\u0131zl\u0131ca koordine olabilecektir. Kapsaml\u0131 bir planlama, ge\u00e7i\u015fin sadece teknik bir s\u00fcre\u00e7 olmad\u0131\u011f\u0131n\u0131, ayn\u0131 zamanda bir proje y\u00f6netimi ba\u015far\u0131s\u0131 oldu\u011funu da ortaya koyar.<\/p>\n
Veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc korumak ve uygulama kesintisini minimuma indirmek, sakin bir veritaban\u0131 ge\u00e7i\u015finin en hassas noktalar\u0131ndan biridir. Bu noktada devreye giren en \u00f6nemli mekanizmalardan biri “Change Data Capture (CDC)” teknolojisidir. CDC, kaynak veritaban\u0131ndaki t\u00fcm de\u011fi\u015fiklikleri (ekleme, g\u00fcncelleme, silme) ger\u00e7ek zamanl\u0131 olarak yakalayan ve bunlar\u0131 hedef veritaban\u0131na ileten bir y\u00f6ntemdir. Bu sayede, ilk veri y\u00fcklemesi yap\u0131ld\u0131ktan sonra, kaynak ve hedef aras\u0131ndaki tutarl\u0131l\u0131k s\u00fcrekli olarak sa\u011flanabilir. Bir ba\u015fka etkili strateji ise “iki y\u00f6nl\u00fc senkronizasyon” veya “dual write” yakla\u015f\u0131m\u0131d\u0131r. Bu y\u00f6ntemde, bir s\u00fcre boyunca hem eski hem de yeni veritaban\u0131na ayn\u0131 anda yaz\u0131m yap\u0131l\u0131r. Uygulama, hem okuma hem de yazma i\u015flemleri i\u00e7in her iki veritaban\u0131n\u0131 da kullanabilir veya belirli bir ge\u00e7i\u015f s\u00fcresi boyunca yaz\u0131mlar\u0131 her ikisine de yaparken okumalar\u0131 eski veritaban\u0131ndan ger\u00e7ekle\u015ftirebilir.<\/p>\n
Veri do\u011frulama mekanizmalar\u0131 da hayati \u00f6neme sahiptir. Ge\u00e7i\u015fin her a\u015famas\u0131nda, kaynak ve hedef veritabanlar\u0131 aras\u0131ndaki veri tutarl\u0131l\u0131\u011f\u0131 kontrol edilmelidir. Bu, sat\u0131r say\u0131lar\u0131n\u0131 kar\u015f\u0131la\u015ft\u0131rmaktan, belirli s\u00fctunlar\u0131n toplamlar\u0131n\u0131 veya hash de\u011ferlerini do\u011frulamaya kadar \u00e7e\u015fitli y\u00f6ntemlerle yap\u0131labilir. Otomatik do\u011frulama ara\u00e7lar\u0131 veya \u00f6zel olarak yaz\u0131lm\u0131\u015f komut dosyalar\u0131 bu s\u00fcre\u00e7te b\u00fcy\u00fck kolayl\u0131k sa\u011flar. Ayr\u0131ca, uygulaman\u0131n yeni veritaban\u0131yla nas\u0131l etkile\u015fim kuraca\u011f\u0131n\u0131 test etmek i\u00e7in ge\u00e7i\u015f \u00f6ncesinde kapsaml\u0131 entegrasyon ve performans testleri yap\u0131lmal\u0131d\u0131r. Bu, sadece veritaban\u0131 taraf\u0131ndaki de\u011fil, ayn\u0131 zamanda uygulama katman\u0131ndaki potansiyel uyumsuzluklar\u0131 da ortaya \u00e7\u0131kar\u0131r. T\u00fcm bu mekanizmalar bir araya geldi\u011finde, mevcut hizmeti kesintiye u\u011fratmadan, veri b\u00fct\u00fcnl\u00fc\u011f\u00fcnden \u00f6d\u00fcn vermeden g\u00fcvenli bir ge\u00e7i\u015f yolu in\u015fa edilmi\u015f olur.<\/p>\n
Planlama a\u015famas\u0131 tamamland\u0131ktan sonra, s\u0131ra teorik stratejileri prati\u011fe d\u00f6kmeye gelir. Bu b\u00f6l\u00fcm, \u015fema ve veri ta\u015f\u0131mas\u0131ndan canl\u0131 senkronizasyona ve kapsaml\u0131 testlere kadar olan uygulama ad\u0131mlar\u0131n\u0131 detayland\u0131racakt\u0131r. Bu s\u00fcre\u00e7lerin her biri, veritaban\u0131 ge\u00e7i\u015finin dramas\u0131z olmas\u0131n\u0131 sa\u011flamak i\u00e7in titizlikle ele al\u0131nmal\u0131d\u0131r.<\/p>\n
\u0130lk ad\u0131m, kaynak veritaban\u0131n\u0131n \u015femas\u0131n\u0131 hedef veritaban\u0131na ta\u015f\u0131makt\u0131r. Bu genellikle en az karma\u015f\u0131k olan k\u0131s\u0131md\u0131r, ancak yine de dikkat gerektirir. Veri tipleri, k\u0131s\u0131tlamalar (primary keys, foreign keys, unique constraints), indeksler, tetikleyiciler ve sakl\u0131 yordamlar hedef veritaban\u0131n\u0131n syntax’\u0131na uygun hale getirilmelidir. Baz\u0131 veritabanlar\u0131 aras\u0131nda do\u011frudan e\u015fde\u011ferlik olmayabilir (\u00f6rne\u011fin, SQL Server’daki <\/code><\/p>\n Bu ilk y\u00fckleme, genellikle b\u00fcy\u00fck veri k\u00fcmeleri i\u00e7in zaman al\u0131c\u0131 olabilir, bu nedenle dikkatli planlama ve potansiyel performans sorunlar\u0131n\u0131 \u00f6nceden test etme \u00f6nemlidir. Veriler ta\u015f\u0131nd\u0131ktan sonra, kaynak ve hedef veritaban\u0131ndaki veri say\u0131lar\u0131n\u0131n ve temel istatistiklerin (\u00f6rne\u011fin, en d\u00fc\u015f\u00fck\/en y\u00fcksek de\u011ferler, ortalamalar) kar\u015f\u0131la\u015ft\u0131r\u0131lmas\u0131, ilk veri b\u00fct\u00fcnl\u00fc\u011f\u00fc kontrol\u00fc i\u00e7in iyi bir ba\u015flang\u0131\u00e7 noktas\u0131d\u0131r.<\/p>\n \u0130lk veri y\u00fcklemesi yap\u0131ld\u0131ktan sonra, as\u0131l zorluk kaynak veritaban\u0131nda meydana gelen s\u00fcrekli de\u011fi\u015fiklikleri hedef veritaban\u0131na aktarmakt\u0131r. \u0130\u015fte burada canl\u0131 veri senkronizasyonu devreye girer. \"\u00c7ift yazma\" (dual write) yakla\u015f\u0131m\u0131, uygulama katman\u0131nda hem eski hem de yeni veritaban\u0131na e\u015f zamanl\u0131 olarak veri yazmay\u0131 i\u00e7erir. Bu, ge\u00e7i\u015f s\u00fcrecinde uygulaman\u0131n her iki veritaban\u0131yla da etkile\u015fim kurmas\u0131n\u0131 sa\u011flar ve kesintisiz hizmet sunumu i\u00e7in kritik bir ad\u0131md\u0131r. Uygulama, eski veritaban\u0131ndan okumaya devam ederken, t\u00fcm yeni yazma i\u015flemlerini her iki veritaban\u0131na da g\u00f6nderir. Bu sayede, yeni veritaban\u0131 s\u00fcrekli olarak g\u00fcncel kal\u0131r. Ancak, \u00e7ift yazma deseninin baz\u0131 zorluklar\u0131 vard\u0131r: her iki yazma i\u015fleminin de ba\u015far\u0131l\u0131 olmas\u0131 gerekir, aksi takdirde veri tutars\u0131zl\u0131klar\u0131 olu\u015fabilir. Ayr\u0131ca, uygulaman\u0131n performans\u0131na ekstra y\u00fck bindirebilir.<\/p>\n Alternatif olarak, Change Data Capture (CDC) ara\u00e7lar\u0131 (\u00f6rne\u011fin Debezium, Fivetran, veritaban\u0131n\u0131n kendi CDC \u00f6zellikleri) veritaban\u0131 d\u00fczeyinde de\u011fi\u015fiklikleri yakalayarak hedef veritaban\u0131na aktar\u0131r. Bu y\u00f6ntem, uygulama katman\u0131nda de\u011fi\u015fiklik yapma ihtiyac\u0131n\u0131 azalt\u0131r ve daha \u015feffaf bir senkronizasyon sa\u011flar. CDC genellikle daha az riskli ve daha performansl\u0131d\u0131r. Senkronizasyon s\u00fcrecinde, veri tutarl\u0131l\u0131k kontrolleri d\u00fczenli olarak yap\u0131lmal\u0131, kaynak ve hedef veritabanlar\u0131ndaki verilerin birebir ayn\u0131 oldu\u011fundan emin olunmal\u0131d\u0131r. Bu a\u015fama, uygulaman\u0131n yeni veritaban\u0131na tamamen ge\u00e7irilmesinden \u00f6nceki kritik \"\u0131s\u0131nma\" d\u00f6nemidir ve herhangi bir veri tutars\u0131zl\u0131\u011f\u0131n\u0131n erken tespit edilmesini sa\u011flar.<\/p>\n Verilerin senkronize edildi\u011fi bu \"ge\u00e7i\u015f faz\u0131\" s\u0131ras\u0131nda, uygulaman\u0131n yeni veritaban\u0131 ile uyumlulu\u011funu test etmek hayati \u00f6nem ta\u015f\u0131r. Bu, sadece i\u015flevsellik testlerini de\u011fil, ayn\u0131 zamanda performans, g\u00fcvenlik ve y\u00fck testlerini de i\u00e7erir. K\u00fc\u00e7\u00fck bir kullan\u0131c\u0131 grubuyla \"kanarya da\u011f\u0131t\u0131m\u0131\" (canary deployment) yaparak veya A\/B testleri uygulayarak, uygulaman\u0131n yeni veritaban\u0131yla nas\u0131l performans g\u00f6sterdi\u011fini ger\u00e7ek d\u00fcnya ko\u015fullar\u0131nda g\u00f6zlemleyebilirsiniz. Ayr\u0131ca, t\u00fcm temel i\u015f s\u00fcre\u00e7lerinin yeni veritaban\u0131 \u00fczerinde do\u011fru \u00e7al\u0131\u015ft\u0131\u011f\u0131ndan emin olmak i\u00e7in kapsaml\u0131 entegrasyon testleri yap\u0131lmal\u0131d\u0131r.<\/p>\n En \u00f6nemlisi, bir \"geri d\u00f6n\u00fc\u015f\" (rollback) plan\u0131na sahip olmakt\u0131r. Her ne kadar dramadan ka\u00e7\u0131nmak istesek de, en iyi planlanm\u0131\u015f ge\u00e7i\u015flerde bile beklenmedik sorunlar ortaya \u00e7\u0131kabilir. Bu durumda, t\u00fcm sistemi h\u0131zl\u0131 ve g\u00fcvenli bir \u015fekilde eski veritaban\u0131na geri d\u00f6nd\u00fcrebilecek sa\u011flam bir plan\u0131n\u0131z olmal\u0131d\u0131r. Rollback plan\u0131 \u015funlar\u0131 i\u00e7ermelidir:<\/p>\n T\u00fcm bu test ve geri d\u00f6n\u00fc\u015f haz\u0131rl\u0131klar\u0131, ge\u00e7i\u015fin son a\u015famas\u0131 olan \"kesin ge\u00e7i\u015f\" (cutover) s\u0131ras\u0131nda g\u00fcvenle ilerlemenizi sa\u011flar. Bu sayede, t\u00fcm riskler \u00f6nceden belirlenmi\u015f ve olas\u0131 sorunlara kar\u015f\u0131 haz\u0131rl\u0131kl\u0131 olunmu\u015f olur.<\/p>\n Her veritaban\u0131 ge\u00e7i\u015fi kendine \u00f6zg\u00fc zorluklar bar\u0131nd\u0131r\u0131r. Ancak, bu zorluklar\u0131n \u00fcstesinden gelmek i\u00e7in ileri d\u00fczey stratejiler ve modern ara\u00e7lar mevcuttur. \u00d6zellikle b\u00fcy\u00fck veri k\u00fcmeleri, karma\u015f\u0131k veri tipleri veya performans beklentileri y\u00fcksek sistemler i\u00e7in standart \u00e7\u00f6z\u00fcmler yetersiz kalabilir. Bu b\u00f6l\u00fcmde, bu gibi senaryolara y\u00f6nelik ipu\u00e7lar\u0131 ve mobil uyumluluk gibi ek konular\u0131 ele alaca\u011f\u0131z.<\/p>\n B\u00fcy\u00fck veri k\u00fcmeleriyle \u00e7al\u0131\u015f\u0131rken, ge\u00e7i\u015fin kendisi performans sorunlar\u0131na neden olabilir. Milyarlarca sat\u0131rl\u0131k tablolar\u0131 ta\u015f\u0131mak veya senkronize etmek haftalar s\u00fcrebilir. Bu durumda, veritaban\u0131 sharding (par\u00e7alama) veya partitioning (b\u00f6l\u00fcmleme) gibi teknikler devreye girebilir. Veriler, mant\u0131ksal veya fiziksel olarak daha k\u00fc\u00e7\u00fck par\u00e7alara b\u00f6l\u00fcnerek paralel i\u015flem yetene\u011fi art\u0131r\u0131l\u0131r ve ge\u00e7i\u015f s\u00fcresi k\u0131salt\u0131l\u0131r. \u00d6rne\u011fin, b\u00fcy\u00fck bir tabloyu tarih aral\u0131\u011f\u0131na g\u00f6re b\u00f6lerek, her bir par\u00e7ay\u0131 ayr\u0131 ayr\u0131 ta\u015f\u0131yabilir ve sonras\u0131nda birle\u015ftirebilirsiniz. Karma\u015f\u0131k veri tipleri, ge\u00e7i\u015flerde ba\u015f a\u011fr\u0131s\u0131 yaratabilir. JSONB (PostgreSQL), XML (SQL Server), co\u011frafi (GIS) veriler veya \u00f6zel UDT'ler (User-Defined Types) gibi yap\u0131lar, hedef veritaban\u0131nda do\u011frudan e\u015fde\u011ferine sahip olmayabilir. Bu gibi durumlarda, veri d\u00f6n\u00fc\u015ft\u00fcrme (data transformation) katmanlar\u0131 veya \u00f6zel scriptler geli\u015ftirerek verilerin do\u011fru formatta aktar\u0131lmas\u0131 sa\u011flanmal\u0131d\u0131r. Bu s\u00fcre\u00e7, ge\u00e7i\u015fin en detayl\u0131 m\u00fchendislik gerektiren k\u0131s\u0131mlar\u0131ndan biri olabilir ve dikkatli bir \u015fekilde planlanmal\u0131d\u0131r.<\/p>\n Bulut tabanl\u0131 ge\u00e7i\u015f ara\u00e7lar\u0131, bu s\u00fcre\u00e7leri \u00f6nemli \u00f6l\u00e7\u00fcde kolayla\u015ft\u0131rabilir. AWS Database Migration Service (DMS), Azure Data Migration Service ve Google Cloud Database Migration Service gibi platformlar, farkl\u0131 kaynaklardan farkl\u0131 hedeflere veri ta\u015f\u0131ma ve s\u00fcrekli senkronizasyon i\u00e7in g\u00fc\u00e7l\u00fc ve y\u00f6netilen hizmetler sunar. Bu ara\u00e7lar, \u015fema d\u00f6n\u00fc\u015ft\u00fcrme, veri tipleri e\u015fleme ve CDC \u00f6zelliklerini genellikle kutudan \u00e7\u0131kt\u0131\u011f\u0131 gibi destekler. B\u00f6ylece, ekip kendi ara\u00e7lar\u0131n\u0131 geli\u015ftirmek yerine ge\u00e7i\u015fin i\u015f mant\u0131\u011f\u0131na odaklanabilir. Ayr\u0131ca, bu hizmetler genellikle \u00f6l\u00e7eklenebilirlik ve y\u00fcksek eri\u015filebilirlik sunarak b\u00fcy\u00fck \u00f6l\u00e7ekli ge\u00e7i\u015fleri daha g\u00fcvenli hale getirir.<\/p>\n Geli\u015fen teknolojilerle birlikte, uygulamalar\u0131n farkl\u0131 cihazlarda d\u00fczg\u00fcn \u00e7al\u0131\u015fmas\u0131 da kritik hale gelmi\u015ftir. Mobil uyumluluk, kullan\u0131c\u0131 deneyimini do\u011frudan etkileyen bir fakt\u00f6rd\u00fcr. Veritaban\u0131 ge\u00e7i\u015finin do\u011frudan mobil uyumlulukla ili\u015fkisi olmasa da, yeni veritaban\u0131n\u0131n performans\u0131 ve API'lar\u0131n tepki s\u00fcresi mobil uygulamalar\u0131n performans\u0131n\u0131 etkileyebilir. Bu nedenle, ge\u00e7i\u015f sonras\u0131 testler mobil uygulama senaryolar\u0131n\u0131 da i\u00e7ermelidir. Ayr\u0131ca, modern web uygulamalar\u0131 i\u00e7in mobil uyumlu HTML ve CSS yakla\u015f\u0131mlar\u0131, responsive tasar\u0131m prensipleri kullan\u0131larak hayata ge\u00e7irilir. A\u015fa\u011f\u0131daki \u00f6rnek, temel bir mobil uyumlu CSS yap\u0131s\u0131n\u0131 g\u00f6stermektedir:<\/p>\nNVARCHAR(MAX)<\/code> ile PostgreSQL’deki TEXT<\/code>). Bu durumda, d\u00f6n\u00fc\u015f\u00fcm kurallar\u0131 belirlenmelidir. Bir\u00e7ok veritaban\u0131 y\u00f6netim sistemi, \u015fema d\u00f6n\u00fc\u015ft\u00fcrme ve ta\u015f\u0131ma i\u00e7in kendi ara\u00e7lar\u0131n\u0131 sunar. \u00d6rne\u011fin, AWS Database Migration Service (DMS) veya Azure Data Migration Service gibi bulut tabanl\u0131 hizmetler, farkl\u0131 veritabanlar\u0131 aras\u0131ndaki \u015fema d\u00f6n\u00fc\u015f\u00fcm\u00fcn\u00fc otomatikle\u015ftirebilir. \u015eema ta\u015f\u0131nd\u0131ktan sonra, kaynak veritaban\u0131ndaki mevcut verilerin ilk y\u00fcklemesi (initial load) ger\u00e7ekle\u015ftirilir. Bu genellikle, uygulaman\u0131n belirli bir s\u00fcre \u00e7evrimd\u0131\u015f\u0131 kalmas\u0131 gereken veya sadece okuma modunda \u00e7al\u0131\u015ft\u0131\u011f\u0131 bir bak\u0131m penceresinde yap\u0131l\u0131r.<\/p>\n\n-- SQL Server'dan bir tablonun \u015femas\u0131n\u0131 ve ilk verilerini kopyalama \u00f6rne\u011fi\n-- Ad\u0131m 1: SQL Server'dan tablo yap\u0131s\u0131n\u0131 sorgulama (\u00f6rnek)\nSELECT COLUMN_NAME, DATA_TYPE, CHARACTER_MAXIMUM_LENGTH\nFROM INFORMATION_SCHEMA.COLUMNS\nWHERE TABLE_NAME = 'Urunler';\n\n-- Ad\u0131m 2: PostgreSQL'de e\u015fde\u011fer tablo olu\u015fturma\n-- (Veri tipleri ve k\u0131s\u0131tlamalar PostgreSQL'e g\u00f6re ayarlanmal\u0131)\nCREATE TABLE Urunler (\n UrunID SERIAL PRIMARY KEY,\n Ad VARCHAR(150) NOT NULL,\n Aciklama TEXT,\n Fiyat DECIMAL(10, 2) NOT NULL,\n StokAdedi INT DEFAULT 0\n);\n\n-- Ad\u0131m 3: SQL Server'dan verileri d\u0131\u015fa aktarma (\u00f6rne\u011fin CSV format\u0131nda)\n-- SQL Server Management Studio veya BCP utility kullan\u0131labilir.\n\n-- Ad\u0131m 4: PostgreSQL'e verileri i\u00e7e aktarma (\u00f6rne\u011fin COPY komutu ile)\n-- COPY Urunler (UrunID, Ad, Aciklama, Fiyat, StokAdedi)\n-- FROM '\/path\/to\/urunler.csv'\n-- DELIMITER ','\n-- CSV HEADER;\n<\/pre>\nCanl\u0131 Veri Senkronizasyonu ve \u00c7ift Yazma (Dual Write) Derinlemesi<\/h3>\n
\n\n# \u00d6rnek Python Flask uygulamas\u0131 ile dual write (\u00c7ift Yazma)\nfrom flask import Flask, request, jsonify\nimport psycopg2\nimport pyodbc # SQL Server i\u00e7in\n\napp = Flask(__name__)\n\n# PostgreSQL (Yeni Veritaban\u0131) ba\u011flant\u0131 bilgileri\nPG_DBNAME = \"new_database\"\nPG_USER = \"postgres\"\nPG_PASSWORD = \"your_pg_password\"\nPG_HOST = \"localhost\"\n\n# SQL Server (Eski Veritaban\u0131) ba\u011flant\u0131 bilgileri\nSQL_SERVER = \"localhost\"\nSQL_DATABASE = \"old_database\"\nSQL_UID = \"sa\"\nSQL_PWD = \"your_sql_password\"\n\ndef get_pg_connection():\n return psycopg2.connect(f\"dbname={PG_DBNAME} user={PG_USER} password={PG_PASSWORD} host={PG_HOST}\")\n\ndef get_sql_connection():\n return pyodbc.connect(f\"DRIVER={{ODBC Driver 17 for SQL Server}};SERVER={SQL_SERVER};DATABASE={SQL_DATABASE};UID={SQL_UID};PWD={SQL_PWD}\")\n\n@app.route('\/api\/musteriler', methods=['POST'])\ndef musteri_ekle():\n data = request.json\n ad = data.get('ad')\n soyad = data.get('soyad')\n email = data.get('email')\n\n if not all([ad, soyad, email]):\n return jsonify({\"hata\": \"Ad, Soyad ve Email alanlar\u0131 zorunludur.\"}), 400\n\n pg_conn = None\n sql_conn = None\n try:\n # PostgreSQL'e yazma\n pg_conn = get_pg_connection()\n pg_cur = pg_conn.cursor()\n pg_cur.execute(\"INSERT INTO Musteriler (Ad, Soyad, Email) VALUES (%s, %s, %s) RETURNING MusteriID\", (ad, soyad, email))\n yeni_pg_id = pg_cur.fetchone()[0]\n pg_conn.commit()\n\n # SQL Server'a yazma\n sql_conn = get_sql_connection()\n sql_cur = sql_conn.cursor()\n sql_cur.execute(\"INSERT INTO Musteriler (Ad, Soyad, Email) VALUES (?, ?, ?)\", ad, soyad, email)\n sql_conn.commit()\n\n return jsonify({\"mesaj\": \"M\u00fc\u015fteri ba\u015far\u0131yla eklendi (dual write)\", \"yeni_id\": yeni_pg_id}), 201\n\n except Exception as e:\n if pg_conn:\n pg_conn.rollback() # PostgreSQL'deki i\u015flemi geri al\n if sql_conn:\n sql_conn.rollback() # SQL Server'daki i\u015flemi geri al\n return jsonify({\"hata\": f\"M\u00fc\u015fteri eklenirken bir hata olu\u015ftu: {str(e)}\"}), 500\n finally:\n if pg_conn:\n pg_cur.close()\n pg_conn.close()\n if sql_conn:\n sql_cur.close()\n sql_conn.close()\n\nif __name__ == '__main__':\n app.run(debug=True, port=5000)\n<\/code><\/pre>\nKapsaml\u0131 Test ve Geri D\u00f6n\u00fc\u015f (Rollback) Haz\u0131rl\u0131klar\u0131<\/h3>\n
\n
Zorluklar, \u0130leri D\u00fczey \u00c7\u00f6z\u00fcmler ve Mobil Uyumlu Yakla\u015f\u0131mlar<\/h2>\n
\n