pg_comparator - מקוון בענן

תָכְנִית:

שֵׁם

pg_comparator - השוואה וסנכרון יעיל של תוכן טבלה

תַקצִיר

pg_comparator [אפשרויות כמו - עזרה --אוֹפְּצִיָה --איש] conn1 conn2

תיאור

סקריפט זה מבצע השוואה יעילה ברשת ובזמן או סנכרון של שניים
אולי שולחנות גדולים PostgreSQL, MySQL or SQLite מסדי נתונים, כדי לזהות שהוכנסו,
טופלים מעודכנים או נמחקים בין הטבלאות הללו. האלגוריתם יעיל במיוחד אם
ההבדלים הצפויים קטנים יחסית.

היישום די כללי: מפתחות מרובי עמודות (אבל חייב להיות מפתח!), לא
הנחה של סוגי נתונים אחרים שניתן להטיל אותם לטקסט, תת-קבוצת עמודות יכולה להיות
משמש להשוואה, טיפול בערכי NULL...

סקריפט זה מתמקד באלגוריתם ההשוואה, ומכאן האפשרויות הרבות. העובדה שזה
עשוי לעשות כל דבר שימושי, כגון בדיקה שכלי שכפול אכן משכפל
הנתונים שלך, או כגון סנכרון טבלאות, הם תופעת לוואי בלבד.

אפשרויות

האפשרויות מאפשרות לבקש עזרה או להתאים כמה פרמטרים פנימיים. אות אחת קצרה
אפשרויות זמינות גם, בדרך כלל עם האות הראשונה של שם האפשרות.

"--aggregate=(sum|xor)" או "-a (sum|xor)"
גם פונקציית צבירה שתשמש לסיכומים XOR or סכום. זה חייב לפעול
התוצאה של פונקציית checksum. עבור PostgreSQL ו- SQLite, ה XOR לְקַבֵּץ
צריך לטעון. יש בעיה חתומה/לא חתומה ב-hash המפתח בעת השימוש XOR
להשוואת טבלאות ב-MySQL או SQLite לעומת PostgreSQL. אנו מספקים "ISUM" חדש
מצטבר עבור SQLite מכיוון שגם "SUM" וגם "TOTAL" עושים טיפול לא תואם עם
מספר שלם עולה על גדותיו.

ברירת המחדל היא סכום מכיוון שהוא זמין כברירת מחדל ועובד במצב מעורב.

"--שאל-תעבור"
בקש סיסמאות באופן אינטראקטיבי. ראה גם אפשרות "--env-pass" למטה.

ברירת המחדל היא לא לבקש סיסמאות.

"--אסינכרוני" או "-A", "--לא-אסינכרוני" או "-X"
האם להפעיל שאילתות אסינכרוניות. זה מספק קצת מקבילות, אולם השניים
החיבורים מסונכרנים פחות או יותר לכל שאילתה.

ברירת המחדל היא להשתמש בשאילתות אסינכרוניות כדי לאפשר מקביליות מסוימת.

"--checksum-computation=(create|insert)" או "--cc=..."
כיצד ליצור את טבלת הבדיקות. להשתמש לִיצוֹר כדי להשתמש ב-"CREATE ... AS SELECT ..."
שאילתה, או להכניס להשתמש בשאילתה "CREATE ...; INSERT ... SELECT ...". הרצון הקודם
דורשים ספירה נוספת כדי לקבל את גודל הטבלה, אז בסופו של דבר יש שניים
שאילתות בכל מקרה. יש בעיה בגודל הסוג עם להכניס אסטרטגיה על MySQL, ה
אורך מחרוזת המפתח המצטבר חייב להיות מתחת ל-64 בתים.

ברירת המחדל היא לִיצוֹר כי זה תמיד עובד עבור שני מסדי הנתונים.

"--checksum-function=fun" או "--cf=fun" או "-c fun"
גם פונקציית Checksum לשימוש ck, fnv or md5. עבור PostgreSQL, MySQL ו-SQLite
ובלבד ck ו fnv יש לטעון פונקציות checksum לתוך מסדי הנתונים היעד.
בחירה md5 גם לא מגיע בחינם: יש לטעון את פונקציות הקאסט שסופקו
לתוך מסדי הנתונים היעד והחישוב יקר יותר.

ברירת המחדל היא ck, שהוא מהיר, במיוחד אם הפעולה קשורה למעבד וה-
רוחב הפס גבוה למדי.

"--checksum-size=n" או "--check-size=n" או "--cs=n" או "-zn"
גודל בדיקת טופל, חייב להיות 2, 4 or 8 בתים. גודל הבדיקה של המפתח הוא תמיד 4 בתים
ארוך.

ברירת המחדל היא 8, כך שההסתברות השלילית הכוזבת נמוכה מאוד. לא צריך להיות
סיבה לשנות את זה.

"--לנקות"
זרוק טבלאות סיכום וסיכום מראש. שימושי לאחר ריצה עם "--no-temp" ו
"--לא ברור", משמש בדרך כלל לניפוי באגים.

ברירת המחדל היא לא לרדת כי אין בו צורך.

"--ברור"
שחרר במפורש טבלאות סיכום בדיקה וסיכום לאחר החישוב. שימו לב שהם כן
ירד באופן מרומז כברירת מחדל כאשר החיבור נסגר מכיוון שהם זמניים, ראה
אפשרות "-(-לא)-זמנית". אפשרות זו שימושית לניפוי באגים.

ברירת המחדל היא לֹא לנקות במפורש את טבלאות הבדיקה והסיכום, כפי שלא
נָחוּץ.

"--debug" או "-d"
הגדר מצב ניפוי באגים. חזור על רמות ניפוי באגים גבוהות יותר. ראה גם "--רבות". היזהר מזה
כמה שמירה על הגדרות אופציות מדלגים תחת ניפוי באגים כדי לאפשר בדיקה
בתנאים שונים.

ברירת המחדל היא לא לפעול במצב ניפוי באגים.

"--env-pass='var'"
קח סיסמה ממשתני הסביבה "var1", "var2" או "var" עבור חיבור ראשון,
שניים, או שניהם. זה מנוסה לפני ששואלים באופן אינטראקטיבי אם "--ask-pass" מוגדר גם כן.

ברירת המחדל היא לא לחפש סיסמאות ממשתני סביבה.

"--expect n" או "-en"
המספר הכולל של הבדלים שניתן לצפות (עדכונים, מחיקות והוספות). אפשרות זו היא
משמש רק עבור מבחני לא רגרסיה. עיין בסעיף בדיקות.

"--folding-factor=7" או "-f 7"
מקדם קיפול: log2 של מספר השורות המקובצות יחד בכל שלב, החל
מהעלים כך שהסיבוב הראשון תמיד מקבץ כמה שיותר שיאים. ה
כוח של שתיים מאפשר להשתמש בחישובים מיסוכים. הערך המינימלי של 1 בונה א
עץ בינארי.

ברירת המחדל של גורם הקיפול log2 הוא 7, כלומר גודל 128 קיפולים. ערך ברירת מחדל זה נבחר
לאחר כמה בדיקות בסיסיות על מקרים בגודל בינוני עם רוחב פס בינוני או נמוך. ערכים מ
4 עד 8 אמורה להיות בחירה סבירה עבור רוב ההגדרות.

"--עזרה" או "-ח"
הצג עזרה קצרה.

"--key-checksum='kcs'" או "--kcs=..."
השתמש בתכונת Key checksum של שם זה, אשר חייבת להיות זמינה כבר בטבלאות
להשוות. אפשרות זו דורשת גם את האפשרות "--tuple-checksum". ראה גם את
קטע דוגמאות להלן כיצד להגדיר טריגר של סכום בדיקה. שקול "--use-key"
במקום זאת, אם כבר יש לך מפתח ראשי עם חלוקה סבירה של מספר שלם.

ברירת המחדל היא לבנות סכימי בדיקה של מפתח וטופל תוך כדי.

"--נעל", "--ללא מנעול"
האם לנעול שולחנות. הגדרת האפשרות עוקפת במפורש את ברירת המחדל בכיוון אחד
או אחר. עבור PostgreSQL, אפשרות זו דורשת "--transaction", המופעל על ידי
ברירת המחדל.

ברירת המחדל תלויה בפעולה הנוכחית: הטבלה היא לֹא נעול לשם השוואה,
אבל זה נעול לסנכרון.

"--long-read-len=0" או "-L 0"
הגדר גודל מקסימלי עבור אובייקטים גדולים בינאריים שנאספו. ובכן, נראה שלפחות מתעלמים ממנו
על ידי מנהל ההתקן של PostgreSQL.

ברירת המחדל היא לשמור על ערך ברירת המחדל שהוגדר על ידי הנהג.

"--אדם" או "-מ"
הצג דף ידני באופן אינטראקטיבי בטרמינל.

"--max-ratio=0.1"
מאמץ חיפוש יחסי מקסימלי. החיפוש מופסק אם מספר התוצאות הוא
מעל סף זה מתבטא יחסית לגודל הטבלה. השתמש ב-2.0 ללא הגבלה
(כל הטפולים נמחקו וחדשים הוכנסו).

ברירת המחדל היא 0.1, כלומר הפרש כולל של 10% מותר לפני הוויתור.

"--max-report=n"
מקסימום מאמץ חיפוש מוחלט. החיפוש מופסק אם מספר ההבדלים
עובר את הסף הזה. אם מוגדרת, האפשרות הקודמת "--max-ratio" תתעלם,
אחרת המאמץ מחושב עם היחס ברגע שגודל הטבלה ידוע.

ברירת המחדל היא לחשב את המספר המרבי של ההבדלים המדווחים על סמך ה
אפשרות "--max-ratio", עם מינימום של 100 הבדלים מותרים.

"--max-levels=0"
המספר המרבי של רמות בשימוש. מאפשר לחתוך קיפול. 0 אומר שאין חתך.
הגדרת ערך של 1 תשתמש רק בטבלת הסכומים, ללא סיכומים. ערך של
3 או 4 יהיו סבירים, מכיוון שהרמות האחרונות של העץ יפות עבור העץ
נוסחת מורכבות תיאורטית, אך לא משפרות את הביצועים בפועל.

ברירת המחדל היא 0.

"--null='טקסט'"
כיצד לטפל בערכי NULL. אוֹ שירים לגיבוב את כל הערכים, כאשר ל-NULL יש אחד מיוחד
ערך hash, או טֶקסט כאשר ערכי NULL מוחלפים במחרוזת "NULL".

ברירת המחדל היא טֶקסט כי זה מהיר יותר.

"--option" או "-o"
הצג סיכום אפשרויות.

"--pg-copy=128"
אפשרות נסיונית להשתמש ב-COPY של PostgreSQL במקום INSERT/UPDATE מתי
סנכרון, לפי נתחים בגודל שצוין.

"--prefix='pgc_cmp'"
קידומת שם, אולי מותאמת לסכימה, משמשת לטבלאות השוואה שנוצרו על ידי
הוספת מספרים אליו. שקול לשנות את הקידומת אם אתה מצפה לכמה
השוואות לרוץ במקביל מול אותו מסד נתונים.

ברירת המחדל היא "pgc_cmp". טבלאות צ'קסום נקראות "pgc_cmp_1_0" ו-"pgc_cmp_2_0", וכן
טבלאות סיכום מקבלים שם על ידי הגדלת המספר האחרון.

"--דווח", "--אין דיווח"
דווח על מפתחות שונים ל-stdout כפי שהם נמצאים.

ברירת המחדל היא לדווח.

"--separator='|'" או "-s '|'"
מחרוזת או תו מפריד המשמשים בעת שרשור עמודות מפתח למחשוב
סכומי בדיקה.

ברירת המחדל לצינור '|' אופי.

"--size=n"
הנח את הערך הזה כגודל הטבלה. זה מספיק כדי שהאלגוריתם יבצע
ובכן שגודל זה הוא בסדר הגודל של גודל השולחן בפועל.

ברירת המחדל היא לבצע שאילתה על גדלי הטבלה, שעליהן מדלגים אם אפשרות זו מוגדרת.

"--source-1='DBI:...'", "--source-2='...'" או "-1 '...'", "-2 '...'"
קח שליטה מלאה במפרט מקור הנתונים של DBI ובעיקר התעלם מההשוואה
אימות חלק מכתובות האתרים של המקור או היעד. אפשר להתחבר אליו
"DBI:Pg:service=backup", השתמש במנהל התקן חלופי, הגדר כל אפשרות המותרת על ידי
מנהל התקן... עיין במדריכים של "DBD::Pg" ו-"DBD:mysql" עבור האפשרויות השונות שניתן
מוגדר דרך מפרט מקור הנתונים של DBI. עם זאת, שרת מסד הנתונים שצוין
בכתובת האתר חייבת להיות עקבית עם מפרט מקור זה כדי שהשאילתות
התחביר הוא הנכון.

ברירת המחדל היא להסתמך על שני הארגומנטים של כתובת האתר.

"--דלג-מוסיף", "--דילג על עדכונים", "--דלג-מחק"
בעת סנכרון, אל תבצע פעולות אלו.

ברירת המחדל תחת "--synchronize" היא לבצע את כל הפעולות.

"--stats=(txt|csv)"
הצג נתונים סטטיסטיים שונים לגבי ההשוואה שבוצעה בפורמט זה. כמו כן, אפשרות
"--stats-name" נותן למבחן שם, שימושי ליצירת קבצי csv שיהיו
מעובד באופן אוטומטי.

ברירת המחדל היא לֹא כדי להציג סטטיסטיקות, כי זה דורש סנכרון נוסף ו
לא בהכרח מעניין את המשתמש.

"--סנכרון" או "-S"
בצע למעשה פעולות כדי לסנכרן את הטבלה השנייה לעומת הראשונה. ובכן, לא
באמת, זו רק ריצה יבשה. זה נעשה למעשה אם אתה מוסיף "--do-it" או "-D". להציל
הנתונים שלך לפני שתנסה משהו כזה!

ברירת המחדל היא לא לסנכרן.

"--זמני", "--לא-זמני"
האם להשתמש בטבלאות זמניות. אם לא, הטבלאות נשמרות כברירת מחדל ב-
סוף, אז הם יצטרכו להימחק ידנית. ראה אפשרות "--נקה" כדי לבקש א
לנקות. אפשרות זו שימושית לניפוי באגים.

ברירת המחדל היא להשתמש בטבלאות זמניות שנמחקות אוטומטית כאשר
החיבור סגור.

"--לא נרשם", "--לא נרשם"
השתמש בטבלאות לא רשומות לאחסון סכומי ביקורת. הטבלאות הללו אינן עסקאות, אז זה
עשוי לזרז קצת את העניינים. עם זאת, הם לא מנקים אוטומטית ב-
סוֹף. ראה אפשרות "--נקה" כדי לבקש ניקוי.

ברירת המחדל היא לא להשתמש בטבלאות לא רשומות.

"--threads" או "-T", "--no-threads" או "-N"
תכונה ניסיוני מאוד.

נסה להשתמש בחוטים כדי לבצע חישובים במקביל, עם קצת הוקוס פוקוס בגלל
מודל פתיל perl לא ממש עובד טוב עם DBI. חוטי פרל כבדים למדי
ואיטי, יותר כמו תהליכי תקשורת מאשר חוטים קלים, באמת.

זה לא עובד בכלל עם PostgreSQL. זה עובד חלקית עם MySQL, ב-
מחיר של כיבוי "--עסקה".

ברירת המחדל היא לֹא להשתמש בשרשורים, מכיוון שזה לא עובד עבור כל מסדי הנתונים.

"--פסק זמן n"
השוואת זמן קצוב לאחר "n" שניות.

ברירת המחדל היא ללא פסק זמן. להיות סבלני.

"--עסקה", "--אין עסקה"
האם לעטוף את כל האלגוריתם בעסקה אחת.

ברירת המחדל היא להשתמש בעסקת עטיפה, מכיוון שנראה שהיא גם מהירה ובטוחה יותר
עשה כך.

"--tuple-checksum='tcs'" או "--tcs=..."
השתמש בתכונה tuple checksum של שם זה, שחייב להיות כבר זמין ב-
טבלאות להשוואה. אפשרות זו דורשת להגדיר גם "--use-key" או
"--key-checksum=..." למעלה. תכונות הבדיקה שסופקו לא יופיעו ב-
רשימות של עמודות מפתח וערכים. עיין גם בסעיף הדוגמאות להלן כיצד להגדיר א
טריגר סכום בדיקה.

ברירת המחדל היא לבנות סכימי בדיקה של מפתח וטופל תוך כדי.

"--use-key" או "-u"
האם להשתמש ישירות בערך המפתח כדי להפיץ tuples בין הענפים. ה
המפתח חייב להיות פשוט, שלם, לא NULL, ומחולק באופן שווה. אם יש לך
חלוקה סבירה של מפתח ראשי של מספר שלם, שקול להשתמש באפשרות זו כדי להימנע מחצי מהמפתח
חישובי גיבוב של טבלת checksum.

ברירת המחדל היא לגיבוב את המפתח, כדי לטפל בכל סוג, הרכב והפצה.

"--use-null", "--no-use-null"
האם להשתמש במידע שעמודה מוכרזת לא NULL כדי לפשט
חישובים על ידי הימנעות מקריאות ל-COALESCE כדי לטפל בערכי NULL.

ברירת המחדל היא להשתמש במידע זה, במחיר של שאילתת מטא נתונים בטבלה.

"--verbose" או "-v"
היו מילוליים לגבי מה שקורה. ככל שאתה שואל יותר, יותר מילולי.

ברירת המחדל היא להיות שקט, כך שאזהרות או שגיאות אפשריות יבלטו.

"--version" או "-V"
הצג מידע על הגרסה וצא.

"--היכן=..."
מצב בוליאני של SQL על טפלות טבלה להשוואה חלקית. שימושי כדי להפחית את
טען אם אתה יודע שההבדלים הצפויים נמצאים בחלקים מסוימים של הנתונים שלך, אמור אותם
חותמת זמן היום... אותו תנאי מועבר משני הצדדים, כך ששני הטבלאות חייבים
להיות די דומה כך שזה יעבוד. זה בדרך כלל המצב.

ברירת המחדל היא להשוות טבלאות שלמות.

טיעונים

שני הארגומנטים מתארים חיבורי מסד נתונים עם התחביר הבא דמוי URL, שבו
סוגריים מרובעים מציינים חלקים אופציונליים. חלקים רבים הם אופציונליים עם ברירת מחדל. המינימום
המפרט הנכון מבחינה תחבירית הוא "/", אבל זה לא אומר שום דבר
מוֹעִיל.

[driver://][login[:pass]@][host][:port]/[base/[[schema.]table[?key[:cols]]]]

ראה את סעיף הדוגמאות למטה, וגם את האפשרויות "--source-*" למעלה.

שים לב שערך ברירת מחדל בשימוש על ידי מנהלי התקנים של DBI עשוי להשתנות עם מנהלי התקן ספציפיים
משתני סביבה, וש-DBI מספק גם ברירות מחדל ועקיפות משלו, אז מה
שקורה בפועל לא תמיד ברור. ערכי ברירת המחדל עבור כתובת האתר השנייה הם לרוב
נלקח מכתובת האתר הראשונה.

נהג
מנהל התקן מסד נתונים לשימוש. להשתמש Pgsql עבור PostgreSQL, MySQL עבור MySQL, 12te עבור SQLite.
ניתן להשוות ולסנכרן מסדי נתונים הטרוגניים, אולם היזהר עדין כל כך
בעיות הקלדה, קידוד והליהוק עשויות למנוע השוואות הטרוגניות או
סנכרון כדי להצליח. ברירת המחדל היא Pgsql עבור החיבור הראשון, ואותו הדבר
ראשון לשני.

עבור SQLite, חלק האימות של כתובת ה-URL (כניסה, מעבר, מארח, יציאה) צפוי
כדי להיות ריק, לכן כתובת האתר המלאה צריכה להיראות כך:

sqlite:///base.db/table?key,col:other,columns

יתר על כן, הגדרת משתנה הסביבה PGC_SQLITE_LOAD_EXTENSION עם
קבצי אובייקט משותפים מופרדים ":" טוענים אותם לתוך SQLite.

התחבר
התחבר לשימוש בעת חיבור למסד נתונים. ברירת המחדל היא שם משתמש עבור החיבור הראשון,
וזהה לחיבור ראשון לשני.

לעבור
סיסמה לשימוש בעת חיבור למסד נתונים. שימו לב שזה רעיון רע לשים א
סיסמה כארגומנט פקודה. ברירת המחדל היא ללא עבור החיבור הראשון, וה-
אותה סיסמה כמו החיבור הראשון עבור השני if החיבור מכוון ל
אותו מארח, יציאה ומשתמש באותה התחברות. ראה גם "--ask-pass" ו-"--env-pass"
אפשרויות.

המארח
שם מארח או IP להתחבר אליו. ברירת המחדל היא המחרוזת הריקה, שמשמעותה התחברות אל
מסד הנתונים על localhost עם שקע UNIX.

נמל
יציאת TCP-IP לחיבור אליה. ברירת המחדל היא 5432 עבור PostgreSQL ו-3306 עבור MySQL.

בסיס
קטלוג מסד נתונים להתחבר אליו. ברירת המחדל היא שם משתמש עבור החיבור הראשון. ברירת המחדל היא
זהה לחיבור הראשון עבור החיבור השני. עבור SQLite, ספק את קובץ מסד הנתונים
שֵׁם. הנתיב הוא יחסי כברירת מחדל, אך ניתן להפוך אותו למוחלט על ידי הצבת
'/' נוסף:

sqlite:////var/cache/sqlite/base.db/table?...

schema.table
הטבלה שאולי מותאמת לסכימה לשימוש לצורך השוואה. אין ברירת מחדל עבור הראשון
חיבור. ברירת המחדל זהה לחיבור הראשון עבור החיבור השני.

שימו לב שאין ל-MySQL תוכניות, אבל באופן מוזר שלהם מסד נתונים הרעיון הוא
ממש כמו א סכימה, אז ל-MySQL באמת אין מאגרי מידע, למרות שיש
משהו בשם הזה. האם אני ברור?

מפתחות
רשימה מופרדת בפסיקים של עמודות מפתח. ברירת המחדל היא המפתח הראשי של הטבלה עבור הראשון
חיבור. ברירת המחדל זהה לחיבור הראשון עבור החיבור השני. המפתח
לא יכול להיות ריק. אם אין לך דרך לזהות את הטפולים שלך, אז אין
נקודה בחיפוש אחר הבדלים.

צווארונים
רשימה מופרדת בפסיקים של עמודות להשוואה. יכול להיות ריק. ברירת המחדל היא כל העמודות אבל
מפתחות לחיבור ראשון. ברירת המחדל זהה לחיבור הראשון עבור החיבור השני.
היזהר ש-"...?key:" פירושו קולס ריק, בעוד "...?key" מגדיר את ברירת המחדל ב-
שאילתות על מטא נתונים של טבלה.

דוגמאות

השווה טבלאות קלווין והובס במשפחת מסד הנתונים ב-localhost, עם מפתח id וטורים
c1 ו c2:

./pg_comparator /family/calvin?id:c1,c2 /family/hobbes

השווה בין טבלאות calvin במסד הנתונים של ברירת המחדל ב-localhost לבין אותה טבלה כברירת מחדל
מסד נתונים על סבלונים, עם מפתח id ועמודה נתונים:

./pg_comparator localhost/family/calvin?id:data sablons/

סנכרון טבלת "משתמש" במסד הנתונים "וויקיפדיה" מ-MySQL ב-"server1" ל-PostgreSQL ב-
"שרת2".

./pg_comparator -S -D --ask-pass \
mysql://calvin@server1/wikipedia/user pgsql://hobbes@server2/

עבור PostgreSQL, אתה יכול להוסיף סכמי מפתח ותחזוקה של טריגר כמו:

-- TABLE Foo(מזהה SERIAL PRIMARY KEY, נתונים ... NOT NULL);
- הוסף מפתח ותכונות בדיקה של tuple
-- ניתן לדלג על סכום הבדיקה של המפתח אם אתה משתמש ב- --use-key,
-- שעבורו המפתח חייב להיות מספר שלם פשוט NOT NULL.
ALTER TABLE Foo
ADD COLUMN key_cs INT4 NOT NULL ברירת מחדל 0,
ADD COLUMN tup_cs INT8 NOT NULL Default 0;
-- פונקציה לעדכון סכום הבדיקה של tuple
-- אם תכונות מסוימות עשויות להיות NULL, הן חייבות להתאחד
CREATE FUNCTION foo_cs() מחזיר את הטריגר כ-$$
התחל
- חישוב סכום בדיקת מפתח
NEW.key_cs = cksum4(NEW.id);
- חישוב סכום בדיקת tuple
NEW.tup_cs = cksum8(NEW.id || '|' || NEW.data);
החזר חדש;
סוֹף; $$ LANGUAGE plpgsql;
-- הגדר טריגר כדי לקרוא לפונקציית עדכון סכום הבדיקה
CREATE TRIGGER foo_cs_trigger
לפני עדכון או הוספה ב- Foo
עבור כל שורה בצע את הליך foo_cs();
-- אם הטבלה Foo לא ריקה בתחילה,
- עדכן את תוכנו כדי להפעיל חישובי שווי בדיקה
עדכון Foo SET id=id;

אז השוואה מהירה, שאינה צריכה לחשב את טבלת הבדיקה הראשונית, יכולה להיות
מתבקש עם:

./pg_comparator --tcs=tup_cs --kcs=key_cs \
admin@server1/app/Foo?id:data hobbes@server2/

מכיוון שהמפתח העיקרי הוא מספר שלם פשוט, ה- key_cs אפשר להשאיר בחוץ ואת ההשוואה
ניתן להפעיל עם:

./pg_comparator --tcs=tup_cs --use-key \
admin@server1/app/Foo?id:data hobbes@server2/

תפוקה

הפלט של הפקודה מורכב משורות המתארות את ההבדלים שנמצאו בין ה
שני שולחנות. הם מתבטאים במונחים של הוספות, עדכונים או מחיקות ושל tuple
מפתחות.

עדכון k
מפתח k tuple מתעדכן מטבלה 1 לטבלה 2. הוא קיים בשתי הטבלאות עם
ערכים שונים.

INSERT k
מפתח k tuple לא מופיע בטבלה 2, אלא רק בטבלה 1. יש להכניס אותו
טבלה 2 כדי לסנכרן אותה מול טבלה 1.

למחוק k
מפתח k tuple מופיע בטבלה 2, אך לא בטבלה 1. יש למחוק אותו מ-2 עד
סנכרן את זה עם טבלה 1.

במקרה של התנגשויות של רמת בדיקת tuple, עלולות להופיע תוצאות שליליות שגויות. שינוי ה
פונקציית checksum תעזור במקרים כאלה. ראה תת-סעיף ניתוח.

תלות

יש צורך בשלוש פונקציות תמיכה במסד הנתונים:

1.
הפונקציה "COALESCE" דואגת לערכי NULL בעמודות.

2.
יש להשתמש בפונקציית checksum כדי לצמצם ולהפיץ ערכי מפתח ועמודות. יכול להיות
ניתן לשנות עם האפשרות "--checksum". ניתן לבחור את הגודל שלו עם
אפשרות "--checksize" (כרגע 2, 4 או 8 בתים). הסכומים גם דורשים גבס להיות
המרה למספרים שלמים בגדלים שונים.

יישומים מתאימים זמינים עבור PostgreSQL וניתן לטעון אותם לשרת
על ידי עיבוד "share/contrib/pgc_checksum.sql" ו-"share/contrib/pgc_casts.sql". חָדָשׁ
סכומי ביקורת והטלות זמינים גם עבור MySQL, ראה "mysql_*.sql". מכשיר טעון
יישום של פונקציות checksum מתאימות זמין גם עבור SQLite, ראה
"sqlite_checksum.*".

סכום הבדיקה "ck" מבוסס על hash של Jenkins ,
אשר מסתמכת על פעולות הוספה, Shift ו-xor פשוטות. סכום הבדיקה "fnv" הוא
בהשראת ה-FNV hash (64 סיביות 1a
גרסה) שמשתמשת בפעולות xor ו-mult מספרים שלמים, אם כי הוספתי גם שינוי מסוים
ולהוסיף כדי לעזור לצבוט ביטים גבוהים.

3.
פונקציית צבירה משמשת לסיכום סיכומי ביקורת עבור טווח של שורות. זה חייב
לפעול על התוצאה של פונקציית checksum. זה עשוי להשתנות עם
אפשרות "--מצטבר".

יישומים מתאימים של אגרגט בלעדי או "xor" זמינים עבור PostgreSQL
וניתן לטעון אותו לשרת על ידי עיבוד "share/contrib/xor_aggregate.sql".

הקובץ "sqlite_checksum.*" מספק גם אגרגטים של "xor" ו-"sum" עבור SQLite
תואמים למאגרי מידע אחרים.

יתר על כן, מספר מודולי perl שימושיים להפעלת סקריפט זה:

· "Getopt::Long" לניהול אופציות.

· "DBI", "DBD::Pg" כדי להתחבר ל-PostgreSQL, "DBD::mysql" כדי להתחבר ל-MySQL, וכן
"DBD::SQLite" כדי להתחבר ל-SQLite.

· "Term::ReadPassword" עבור אפשרות "--ask-pass".

· "Pod::Usage" לחילוץ עצמי של מסמך ("--man" "--opt" "--help").

· "חוטים" עבור גרסת ההברגה הניסיונית עם אפשרות "--חוטים".

· "Digest::MD5" עבור md5 checksum עם SQLite.

מודולים נטענים על ידי הסקריפט רק אם הם נדרשים בפועל.

אַלגוֹרִיתְם

מטרת האלגוריתם היא להשוות את התוכן של שתי טבלאות, אולי על שונות
שרתים מרוחקים, עם מינימום תעבורת רשת. הוא מבוצע בשלושה שלבים.

1.
טבלת שווי ביקורת מחושבת בכל צד עבור טבלת היעד.

2.
טבלת סיכום ברמת האגרוף מחושבת בכל צד על ידי צבירה של נתחים של ה-
טבלת שווי בדיקה. לאחר מכן מבוצעות רמות אחרות של צבירות סיכום עד שיש
רק שורה אחת בטבלה האחרונה, אשר לאחר מכן מאחסנת סכום ביקורת גלובלי עבור השלם
טבלאות יעד ראשוניות.

3.
החל מטבלאות הסיכום העליונות, סכומי ביקורת מצטברים משוווים משניהם
צדדים לחפש הבדלים, עד לטבלת הסכמים הראשונית. מפתחות של שונות
מוצגים tuples.

CHECKSUM טבלה
השלב הראשון מחשב את טבלת סכום הבדיקה הראשונית T(0) בכל צד. בהנחה ש מפתח
הוא עמודות מפתח הטבלה, ו צווארונים הוא עמודות נתוני הטבלה שיש לבדוק עבורן
הבדלים, אז הוא מבוצע על ידי שאילתת טבלת יעד T כדלקמן:

צור טבלה T(0) AS
מקש SELECT AS pk, -- מפתח ראשי
checksum(key) AS kcs, -- key checksum
checksum(key || cols) AS tcs -- tuple checksum
מטי;

המפתח הראשוני נשמר, מכיוון שהוא ישמש להצגת מפתחות שונים בסוף. ה
רציונלי עבור kcs עמודה היא לעשות אקראי את התפלגות ערכי מפתח כדי לאזן
אגרגטים בשלב הבא. המפתח חייב להופיע גם בסכום הבדיקה, אחרת תוכן
מוחלפים בין שני מפתחות לא יתגלו במקרים מסוימים.

סיכום לוחות
כעת אנו מחשבים קבוצה של טבלאות סיכום מדורגות לפי קיבוץ f (גורם מתקפל) סכימי בדיקה
ביחד בכל שלב. הקיבוץ מבוסס על מסכה על kcs עמודה לקחת
היתרון באקראי של סכום הבדיקה. התחיל מ p = 0 אנחנו בונים:

CREATE TABLE T(p+1) AS
SELECT kcs & mask(p+1) AS kcs, -- קבוצת משנה של key checksum
XOR(tcs) AS tcs -- סיכום סיכום בדיקת טופל
FROM T(p)
GROUP BY kcs & mask(p+1);

המסכה (p) מוגדרת כך שהיא מתקבצת יחד בממוצע f סכומי בדיקה ביחד: מסכה(0)
= ceil2(size); mask(p) = mask(p-1)/f; זה מוביל להיררכיה של טבלאות, שכל אחת מהן
סיכום קטן יותר של הקודם:

רָמָה 0
טבלת שווי בדיקה, גודל שורות, כלומר כמה שורות כמו טבלת היעד.

רָמָה 1
טבלת סיכום ראשונה, שורות (גודל/f).

רָמָה p
טבלת סיכום ביניים, שורות (גודל/f**p).

רָמָה n-1
אחת לפני טבלת הסיכום האחרונה, פחות משורות f.

רָמָה n
טבלת סיכום אחרונה, המסכה היא 0, שורה אחת.

חשוב שאותן מסכות ישמשו משני הצדדים כך שהצטברויות יהיו
זהה, מה שמאפשר להשוות בין תוכן תואם משני הצדדים.

לחפש עבור הבדלים
אחרי שכל טבלאות התמיכה הללו בנויות משני הצדדים מגיע החיפוש אחר הבדלים.
בעת בדיקת סיכום הבדיקה של הטבלאות האחרונות (רמה n) עם שורה אחת בלבד, זה כן
בעצם השוואה של סכום הבדיקה של כל תוכן הטבלה. אם הם תואמים, אז
שני השולחנות שווים, וגמרנו. אחרת, אם סכומי הבדיקה הללו שונים, חלקם
יש צורך בחקירה כדי לזהות מפתחות פוגעים.

החקירה מתבצעת על ידי ירידה בהיררכיית הטבלה וחיפוש אחר הכל kcs
לגביו היה הבדל בסכום הבדיקה ברמה הקודמת. אותה שאילתה היא
בוצע משני הצדדים בכל שלב:

בחר kcs, tcs
FROM T(p)
WHERE kcs & mask(p+1) IN (kcs-with-diff-checksums-from-level-p+1)
ORDER BY kcs [וברמה 0: , id];

והתוצאות משני הצדדים מתמזגות יחד. בעת ביצוע הליך המיזוג, ארבע
יכולים להיווצר מקרים:

1.
שניהם kcs ו TCS התאמה. ואז אין הבדל.

2.
למרות kcs אכן תואם, TCS לא. ואז זה kcs ייחקר בשלב הבא
רמה, שכן סיכום הבדיקה שונה. אם אנחנו כבר ברמה האחרונה, אז ה
ניתן להציג מפתח פוגע.

3.
לא kcs התאמה, אחד משלים kcs בצד הראשון. ואז זה kcs תואם
מפתח(ים) שיש להכניס לסנכרון הטבלה השנייה מול הראשונה.

4.
לא kcs התאמה, אחד משלים kcs בצד השני. ואז זה kcs תואם
מפתח(ים) שיש למחוק לסנכרון הטבלה השנייה מול הראשונה.

מקרים 3 ו-4 הם פשוט סימטריים, וזו רק פרשנות להכריע האם
זה הוספה או מחיקה, לוקח את הצד הראשון כהפניה.

אָנָלִיזָה
לתת n להיות מספר השורות, r גודל השורה, f גורם הקיפול, k מספר
הבדלים שיש לגלות, c גודל הבדיקה בסיביות, ולאחר מכן את העלויות לזיהוי
ההבדלים ושיעור השגיאות הוא:

רשת כֶּרֶך
טוב יותר מ k*f*ceil(log(n)/log(f))*(c+log(n)). התוכן של k גושי גודל f
מועבר על עומק העץ, וכל מזהה בלוק הוא בגודל יומן (n) ו
מכיל סכום בדיקה c. זה בלתי תלוי ב r, ואתה רוצה k<<n. עוצמת הקול של
בקשות SQL הוא בערך k*log(n)*ceil(log(n)/log(f)), כרשימה של אי-התאמה
סכומי בדיקה k*log(n) עלול להיגרר על עומק העץ.

מספר of בקשות (עַל כל אחד צַד, מה היא אַלגוֹרִיתְם is סימטרי)
המינימום הוא 6+ceil(log(n)/log(f)) עבור טבלאות שוות, המקסימום הוא 6+2*ceil(log(n)/log(f)).

דיסק I / O תְנוּעָה
הוא על n*r+n*ln(n)*(f/(f-1)).

שקר שלילי הסתברות
כלומר חלק מהטבלאות נחשבות שוות למרות שהן שונות. עם
פונקציית checksum מושלמת, זו ההסתברות להתנגשות checksum בכל נקודה
היכן שהם מחושבים והיו צריכים להיות שונים: בערך
k*ceil(log(n)/log(f))*2**-c. עבור טבלת מיליון שורות, מצפה ל-1000 שינויים עם ה
ערכי ברירת המחדל של פרמטר אלגוריתם, זה בערך 2 ** 10 *3/2**64, זה בערך אחד
סיכוי פנימה 2 ** 52 ריצות מיזוג.

ככל שמקדם הקיפול נמוך יותר f טוב יותר עבור נפח הרשת, אבל גבוה יותר
טוב יותר עבור מספר הבקשות ו-I/Os בדיסק: הבחירה של f מהווה פשרה.

ככל שגודל הבדיקה נמוך יותר c, טוב יותר עבור עוצמת הקול ברשת, אבל גרוע יותר עבור
הסתברות שלילית כוזבת.

אם רוחב הפס הזמין סביר, סביר להניח שההשוואה תהיה קשורה למעבד:
הזמן מושקע בעיקר בחישוב טבלת הסכמים הראשונית. כך אם אתה
מתכנן לבדוק הבדלים לעתים קרובות למדי, שקול לשמור על סכום בדיקה עם tuple
טריגר, ואולי גם סכום בדיקה מפתח, ולהפעיל עם "--tuple-checksum" ו
או "--key-checksum" או "--use-key".

יישום סוגיות
יישום checksum נותן מספרים שלמים, שהם אורך קבוע וקל לביצוע
לתמרן לאחר מכן.

השמיים XOR אגרגט הוא בחירה טובה כי אין בעיה עם הצפה, זה דורש
לקחת בחשבון את כל הסיביות של הקלט, וניתן להגדיר אותו בקלות על כל נתונים בינאריים. ה
סכום aggregate זה גם בסדר, אבל זה דורש סוג של מספר שלם בסיסי.

יש להקפיד על ערכי NULL.

מקדם הקיפול וכל המודולים נלקחים בעוצמה של שניים כדי להשתמש במסכות.

יש ניהול מיוחד של נתחים גדולים של מחיקות או הוספות אשר מיושם
אם כי לא מפורט בסקירה האלגוריתמית ובניתוח המורכבות.

יש כמה מאמצים לבנות יישום תואם PostgreSQL/MySQL של
אלגוריתם, שהוסיף פריצות להתמודדות עם המרות סוגים ודברים אחרים.

התסריט הזה נבדק בצורה סבירה, אבל בגלל אופי ההוכחה של הרעיון שלו יש הרבה
אפשרויות שלא ניתן לבדוק את כולן בשילובן.

הערה
אם הטבלאות להשוואה נמצאות באותו מסד נתונים, שאילתת SQL פשוטה יכולה לחלץ את
הבדלים. בהנחה של טבלאות T1 ו T2 עם מפתח ראשי id ותוכן שאינו ריק נתונים,
ואז ההבדלים ביניהם, ככה T2 שונה מההפניה T1, מסוכם על ידי ה
השאילתה הבאה:

SELECT COALESCE(T1.id, T2.id) מקש AS,
מקרה כאשר T1.id הוא NULL ואז 'מחק'
כאשר T2.id הוא NULL אז 'הכנס'
אחרת 'עדכון'
פעולת END AS
מ-T1 הצטרפות מלאה T2 באמצעות (מזהה)
היכן T1.id הוא NULL -- מחק
או T2.id הוא NULL -- הכנס
או T1.data <> T2.data -- עדכון

ביבליוגרפיה
מאמר הוצג בכנס על הכלי הזה והאלגוריתם שלו: מרוחק השוואה
of מסד נתונים לוחות by פביאן ארנב, בכנס בינלאומי שלישי על התקדמות ב
מסדי נתונים, ידע ויישומי נתונים (DBKDA), עמ' 23-28, St Marteen, הולנד
האנטילים, ינואר 2011. ISBN: 978-1-61208-002-4. זכויות יוצרים IARIA 2011. מקוון ב-Think
אכפתhttp://www.thinkmind.org/index.php?view=article&articleid=dbkda_2011_2_10_30021>.

האלגוריתם והתסריט נוצרו בהשראת אילוף מה היא מופץ מסד נתונים בעיה: A מקרה
לימוד שימוש MySQL by ג'וזפה מקסיה in Sys Admin כרך 13 מספר 8, אוגוסט 2004, עמ' 29-40. לִרְאוֹת
פרל נזיריםhttp://www.perlmonks.org/index.pl?node_id=381053> לפרטים. במסמך הזה,
מוצגים שלושה אלגוריתמים. הראשון משווה בין שתי טבלאות עם סכום ביקורת
טֶכנִיקָה. השני מוצא הבדלים ב-UPDATE או INSERT על בסיס 2 רמות (checksum
וסיכום) היררכיית טבלה. האלגוריתם הוא א-סימטרי, כמו שאילתות שונות
בוצע על שני הטבלאות להשוואה. נראה שנפח התעבורה ברשת נכנס
k*(f+(n/f)+r), שיש לו הליך מיזוג הסתברותי-באגי, ושהוא עושה
הנחות לגבי התפלגות ערכי מפתח. האלגוריתם השלישי מחפש DELETE
הבדלים המבוססים על ספירה, מתוך הנחה מרומזת שיש רק כאלה
הבדלים.

בניגוד לגישה זו, האלגוריתם הסימטרי המלא שלנו מיישם את כל שלוש המשימות
בבת אחת, כדי למצוא את UPDATE, מחק ו-INSERT בין שתי הטבלאות. סכום הבדיקה ו
סיכום ברעיון ברמה היררכית נעשה שימוש חוזר ומוכלל כדי להפחית את האלגוריתמי
מורכבות.

מנקודת המבט של היישום, התסריט הוא פרמטרי ככל האפשר עם רבים
אפשרויות, ומניח מעט הנחות לגבי מבני טבלה, סוגים וערכים.

השתמש ב-pg_comparator באינטרנט באמצעות שירותי onworks.net