שכפול נתונים
שכפול של מסד נתונים

מערכות ניהול מסדי נתונים רבות מאפשרות שכפול בדרך כלל עם יחסי ראשי-משני בין העותק המקורי והעותקים המשניים - כאשר העותק הראשי רושם את העדכונים, הם מופצים לעותקים המשניים, העותקים המשניים שולחים הודעה המציינת כי קיבלו את העדכון בהצלחה ואז נשלחים עדכונים נוספים (בחלק מהמערכות יש תמיכה גם בשליחה מחדש של העדכונים עד שהם מיושמים בהצלחה בעותקים המשניים). מערכת כזאת מאפשרת גישת כתיבה רק למערכת אחת בעוד שאר המערכות מאפשרות רק קריאה (למשל זאת הדרך בה עובדת מערכת ויקיפדיה). מערכת כזאת יכולה להתבסס על קובץ היומן שמסדי נתונים כותבים לרוב את הנתונים במהירות רבה מאוד אליו כחלק מהפעילות הסטנדרטית שלהם  ואותו יכולים לקרוא גם מערכות חיצוניות (הגם שהקריאה עצמה מחייבת היכרות עם הפורמט של מסד הנתונים המסוים). אפשרות נוספת היא להתבסס על רענון של תמונות נתונים שנוצרו באמצעות כלי הגיבוי של המערכת ונטענות מהר יחסית. לעומת זאת מערכת כזאת מהווה נקודת כשל יחידה ומעכבת את ביצוע העדכונים על מסד הנתונים הראשי (בשל הצורך בעדכוני מסדי הנתונים המשניים).
חלק מהמערכות תומכות גם בשכפול עם מספר עותקים ראשיים בו ניתן לבצע את העדכונים בכל אחד מעותקי מסד נתונים ולאחר מכן הם מופצים למסדי הנתונים האחרים. בעוד זהו לעיתים קרובות המצב הרצוי הרי הוא מגדיל באופן משמעותי את העלויות והמורכבות של המערכת במידה העלולה להפוך אותה לבלתי מעשית במצבים מסוימים. הבעיה הנפוצה בסוג כזה של מערכות היא מניעת התנגשויות בין טרנזקציות או פתרון שלהן. רוב הפתרונות למניעת התנגשויות הם סנכרוניים או כאלו הדורשים את כל הנתונים, בעוד הפתרונות האסינכרוניים דורשים פתרון של ההתנגשויות. לדוגמה, אם רשומה שונתה בשני מחשבים בו זמנית, מערכת השכפול הדורשת את כל הנתונים מאתרת את הבעיה לפני מתן האישור לבצע את הפעולה ומבטלת את הטרנזקציה בעוד מערכת שכפול שאיננה דורשת את כל הנתונים תאפשר לשתי הטרנזקציות להתבצע ותפעיל פתרון להתנגשויות במהלך הסינכרון מחדש. ההחלטה על פתרון התנגשויות כזה עשויה להיות מבוססת על חותמת הזמן של הטרנזקציה, על היררכיה של השרתים או על לוגיקה מורכבת יותר אשר חייבת להיות עקבית בכל המחשבים.
באופן עקרוני השכפול של מסד נתונים הופך קשה ככל שהמערכת גדלה. בדרך כלל, מודדים את ההיקף בשני ממדים - אופקי ואנכי: המימד האופקי מודד את מספר העותקים של הנתונים והסולם האנכי את העתקי הנתונים הממוקמים במקום מרוחק.
גישות מקובלות לשכפול נתונים במערכות מסדי נתונים כוללות את:
שכפול מבוסס הדק (trigger): רוב תוכנות מסדי הנתונים (כולל  אורקל, IBM DB2, מיקרוסופט SQL Server ו־Sybase Adaptive Server Enterprise ‏(ASE) מציעות פונקציונליות זו. טכניקה זו מטפלת הן בנתונים חדשים והן בעדכון נתונים קיימים והיא תומכת הן במצב סינכרוני והן במצב אסינכרוני (על ידי שמירת נתוני ביניים). שיטה זו מתאימה בעיקר לשכפול סלקטיבי של הנתונים (למשל נתוני כוח אדם הספיציפי ולא טבלאות הקוד הקבועות) ולא לשכפול של כל הנתונים. השיטה מחייבת לרוב לבחור עמודות ספיציפיות, עם סוגי נתונים סטנדרטי ומובנים (לרוב אין תמיכה ב־*LOB-ים למשל) והיא מוגבלת מבחינת שינויי הסכמה המתאפשרים מבלי לשבור את השכפול. ניתן לשפר את הביצועים של שיטה זו על ידי שימוש בשליחה אסינכרונית הצוברת את הנתונים ומשדרת אותם ביחד (ולעומת זאת עלולה להקטין את רמת העדכניות של הנתונים).
שכפול מבוסס SQL: השכפול מתבצע על ידי שליחה תדירה של משפטי SQL ממסד נתונים אחד למשנהו. קוד ה־SQL מכיל נתונים מטבלאות מסוימות נשמר בקובץ ביניים או מבוצע ישירות במסד הנתונים השני. גישה זו רגישה לשינויים בסכמת מסד הנתונים ודורשת בדרך כלל זה ביצוע תחזוקה סדירה על מנת להתייחס אליהם ולכן איננה בשימוש נרחב. גישה זו דורשת גם משאבים משמעותיים לביצוע של קוד ה־SQL (לרוב קוד script המבוצע בזמנים קבועים) הדרוש הן למציאת הנתונים והן לעדכונם. יתרונה של גישה זו הוא בכך שאיננה מחייבת תמיכה מיוחדת של תוכנת מסד הנתונים (מעבר לתמיכה הסטנדרטית בקוד SQL) כך שהיא נתמכת על ידי כל סוגי מסדי הנתונים (מערכות מסוימות כמו Data Gaurd לוגי של אורקל מסוגלות לייצור את קוד ה־SQL הדרוש אוטומטית, מה שמקל על השימוש בטכניקה זו). עם זאת מערכת כזאת מוגבלת על ידי מגבלות השימוש בקוד SQL של המשתמש המריץ אותה במערכת המטרה, דבר המקשה על זיהוי של מבצע הפעולה המקורית (מה שעשוי להיות בעייתי בסביבות מאובטחות).
שכפול מבוסס יומן: גישה זו מבוססת על משלוח יומני הפעילות של מסד הנתונים אל מסד נתונים מרוחק ויישום של הפעולות שם כך שהנתונים במסד המרוחק מסתנכרנים עם המקור. אתחול התהליך מתבצע על בסיס עותק מלא של מסד הנתונים המועתק לשרת האחר. לאחר האתחול יומן הטרנזקציות של מסד הנתונים המקורי נשלח למסד הנתונים המרוחק, לרוב בצורה אסינכרונית. גישה זו יכולה לתמוך בכל גודל של מסד הנתונים וכמות צריכת המשאבים שלה תלויה באופן ישיר בכמות הפעולות המתבצעות בפועל. לרוב ספקי מסדי הנתונים אינם תומכים ביישום פעולות היומן על מערכות מסדי נתונים אחרות אולם ישנן תוכנות צד שלישי התומכות בכך. ישנן גם תוכנות התומכות (כמו אורקל) ביכולת לשלוח רק חלק מהיומן ובכך להקטין את התקשורת ואת צריכת המשאבים של השכפול. מימוש של ספקי צד שלישי של שכפול מסוג זה נתקל לרוב באי תיעוד מלא של היומן ובשינויי מבנה תכופים שלו אולם מצד שני עשוי לאפשר שימוש בגישה זו על מנת לעדכן סוגים שונים של מערכות מסדי נתונים (מה שנתמך לעיתים על ידי הספקים עצמם, למשל Sybase).
בנוסף לגישות אלו המתמקדות בשכפול "פנימי" של מסד הנתונים ניתן לשכפל (גם או רק) את האחסון עליו נשמרים קובצי מסד הנתונים. למשל אורקל תומך ב־ASM שהוא סוג של LVM המיועד למטרה זו ומסדי נתונים אחרים תומכים במערכות חיצוניות למטרה זו (לדוגמה MySQL תומך ב־DBRD למטרה זו). יצירת תמונת נתונים (כל הנתונים בזמן מסוים) נתמכת על ידי סוגי מסדי הנתונים - על ידי רישום של הפעולות שבוצעו ביומן, או על ידי שמירת רישום של הפעולות האחרונות במסד הנתונים (למשל rollback segments או undo tablespace באורקל) או על ידי יצירת תמונות בקבצים נפרדים (למשל ב־SQL Serever בסיוע Volume Shadow Copy Service של חלונות). גם אשכולות יכולים לשמש למטרה זו (דוגמאות לכך כוללות את RAC של אורקל ושימוש ב־memcached עבור MySQL).
ניתן גם לבצע את השכפול באמצעות וירטואלזציה של מסד הנתונים (בין אם בצד השרת ובין אם בצד הלקוח) כך שכל פעולת כתיבה תכתב למספר מסדי נתונים.
תוצאות השכפול יכולות (עם תלות מסוימת בגישה בה משתמשים בשביל לבצע את השכפול) להיות משלושה סוגים:
תמונת נתונים (לא ניתן לשימוש בגישת היומן) - העתקה מלאה של כל הנתונים הקיימים במסד הנתונים לשרת אחר.
שכפול טרנזקצאלי - השינויים בשרת אחד משוכפלים לשרת אחר (לרוב על ידי היומן). פירוש הדבר כי בכל הזמן שבו משתנים הנתונים הם מופצים ונשלחים לשרת השני, באופן מיידי או מצטבר עד לנקודה מסוימת בזמן או עד כמות מסוימת של נתונים. שכפול כזה הוא טרנזקצאלי כך שכל החלקים התנועה עוברים או אף חלק ממנה, מצב העשוי להיות בעייתי במקרה של עדכונים צולבים בין מסדי הנתונים
מיזוג - שכפול שהוא למעשה מיזוג של שני עותקים של הנתונים שאמורים להיות מסונכרנים. סוג זה עלול ליצור קונפליקטים בין העדכונים ובדרך כלל מבוצע על ידי שליחת תמונת נתונים ראשונית ושליחת עדכונים מאוחרים יותר