מדוע צומת ארכיון של Ethereum מפסיק להגיב לבקשות
צומת ארכיון של Ethereum מגיב לבקשות היסטוריות לבלוקצ'יין עבור כל בלוק — מצב בגובה מסוים, יתרת כתובת לפני התנועה הראשונה, תוצאת קריאה לחוזה שכבר אינו קיים. על זה נשענים ביקורת, אנליטיקה והצלבת עסקאות.
אבל היא מפסיקה להיות ארכיונית בשקט: נקודת הגישה פתוחה, הצומת ברשת, ובבקשות לבלוקים ישנים מתקבלת שגיאה על צומת מצב חסר.
הסיבה הראשונה — מצב האחסון. הלקוח כברירת מחדל מתייחס למצב כאל נגזרת ומוחק ענפים היסטוריים כדי לא לגדול ללא סוף. הצומת מסתנכרן, מגיב לבקשות טריות ונראה בריא, עד שמישהו מבקש בלוק מהעבר.
לצידו — קטיעת הסינכרון של הצומת: תהליך שהופסק בעת אובדן חיבורים או הפעלה מחדש אינו ממשיך מהמקום, אלא נסוג אחורה.
הסיבה השנייה — הדיסק. תצורת ארכיון הופכת את העומס לזרם של קריאות אקראיות לפי מפתחות מצב, והידרדרות של קלט-פלט דיסקי מתגלה לפני שנגמר המקום. הצומת פועל פורמלית, אבל זמן התגובה גדל, בקשות מסתיימות בפסק זמן — ואי-זמינות של ארכיון העסקאות מתרחשת בלי שגיאה אחת בלוגים.
השלישית — תכנון: ההיסטוריה מתבררת כגדולה ממה שהניחו, הדיסק יורד לאפס, והשירות נופל בדיוק כשהאינדוקס מחדש אורך ימים. מפרקים כיצד זה נסגר: איזה פרופיל אחסון לבחור עבור Erigon ו-Reth, כיצד להפריד צומת ארכיון מצומת רגיל ומה לנטר כדי שהכשל יהיה גלוי מראש, ולא לפי תלונת האנליטיקאים.
מה משתנה לאחר סינכרון נכון של הארכיון
צומת ארכיון נבדל מצומת מלא לא בנפח הדיסק, אלא בכך שהמצב נשמר עבור כל בלוק. אם הסינכרון עבר שלא כהלכה, בקשות לבלוקים ישנים עוברות דרך נסיגה והרצה חוזרת במקום קריאה מהדיסק. מכאן עשרות שניות לקריאה אחת, נפילות בפסק זמן אצל האינדקסר ותור שגדל מהר יותר מהגעת התעבורה.
לאחר הרכבה נכונה של הארכיון משתנים שלושה דברים מדידים. מהירות התגובה לבקשות היסטוריות יוצאת ליחידות שניות בהתחממות הראשונה ושברירי שנייה בפניות חוזרות — המצב נקרא ישירות.
תחת עומס מקבילי פרופיל ההשהיות אחיד: הזנב לא מתפשט כשפונים לצומת בו-זמנית אנליטיקה, סייר בלוקים ושירותים פנימיים.
הפעלה מחדש מפסיקה להיות אירוע. הצומת עולה על מצב שכבר נאסף ומדביק רק את הבלוקים האחרונים, ולא משחק מחדש את ההיסטוריה. אנחנו מרכיבים ארכיונים על Erigon ומריצים בדיוק את התרחיש הזה — עצירה, הפעלה, חזרה לכשירות בלי פעולות ידניות.
שלמות היסטוריית העסקאות — תוצאה נפרדת: עקבות, קבלות והעברות פנימיות זמינות לכל התקופה, בלי חוסרים בטווחי בלוקים. בדיוק על זה נשענים דוחות, ביקורת ושחזור יתרות לתאריך כלשהו.
מצבי אחסון נתונים: ארכיוני, מלא ומקוצר
מצב האחסון קובע איזה חלק מהיסטוריית המצבים הצומת מספק לפי בקשה. מצב ארכיוני שומר מצב בכל גובה בלוק, צומת מלא מחזיק מצב נוכחי והיסטוריית בלוקים, ומקוצר — רק כותרות והוכחות. מכך תלוי אילו בקשות אתם משרתים בעצמכם, ואילו ידרשו חיבור למקורות נתונים חיצוניים.
ההבדל מורגש לא ב"בלוק האחרון", אלא בעומק הבקשה. חישוב יתרות היסטוריות, הצלבת אירועים לפי חוזה, ביקורת עסקאות ואינדוקס מחדש דורשים מצב בגובה מסוים — צומת מלא מגיב לבקשה כזו בשגיאה, ולא בנתונים מיושנים. לכן את המצב קובעים לפני הסינכרון הראשוני: מעבר על צומת פעיל משמעו טעינה חוזרת של השרשרת.
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| מצב ארכיוני | אנליטיקה, אינדוקס אירועים, יתרות היסטוריות, דיבוג חוזים | ההיסטוריה גדלה באופן ליניארי עם אורך השרשרת ותופסת פי כמה יותר מקום, הסינכרון הראשוני הוא הארוך ביותר |
| צומת מלא | ארנקים, relay, שירותים על מצב עדכני | מצב בגבהים קודמים אינו זמין, בקשות היסטוריות עמוקות אינן נענות |
| צומת מקוצר | אימות תשלומים, אינטגרציות קלות, תרחישי לקוח | לא היסטוריה ולא מצב — תלוי בספקי נתונים חיצוניים |
את המצב ואת לקוח ההרצה בוחרים יחד: לא כל לקוח תומך באופן מלא באותה מידה באחסון ארכיוני ומספק מצבים היסטוריים דרך הממשק הסטנדרטי. אנחנו בודקים זאת על רשת בדיקה לפני פריסה, כדי לא לטעון מחדש את הרשת הראשית.
שלבי הפריסה והסינכרון של הצומת
פריסת צומת ארכיון אינה "להוריד לקוח ולהריץ", אלא רצף שבו טעות בשלב מוקדם עולה בשבועות של סינכרון חוזר. להלן סדר העבודות שלפיו אנחנו מובילים את הפרויקט מהבדיקה ועד למסירה לתפעול.
- בדיקה. קובעים את הרשתות ואת עומק הארכיון: נדרש state היסטורי מלא, רק לוגים או גם עקיבה. מחשבים פרופיל עומס — שיעור הבקשות
eth_getLogsו-debug_trace*לבלוקים היסטוריים, מספר החיבורים המקבילים הרצוי. זה קובע גם את הלקוח וגם את דרישות הדיסק. - תכנון. בוחרים לקוח הרצה לפי המשימה: Erigon — כשחשוב יותר אחסון קומפקטי והיסטוריה עמוקה, Reth — כשבעדיפות מהירות ההדבקה והיענות ה-RPC. בנפרד מתכננים צומת Arbitrum, אם נדרש גישה להיסטוריית L2. כאן גם — תרשים הפרדת הדיסקים לנתונים, לוגים וצילומי מצב.
- הכנת האחסון. חלוקה ומיטון עם גודל בלוק מתאים ומרווח לגדילה, הגדרת מגבלות מתארים, קובץ swap ומדיניות דחיסה. את האחסון מתכננים כך שהמאגר לא יגדל בצורה מפולתית ויישמר מרווח לבלוקים עתידיים.
- התקנה וטעינה ראשונית. פורסים את הלקוח בסביבה מבודדת, מחברים צילום מצב במקום סינכרון מאפס — זה מקצר את ההגעה לגובה העדכני משבועות לשעות.
- סינכרון הארכיון. מובילים את ההדבקה עד לראש הרשת, תוך בקרה על קצב עיבוד הבלוקים והפער. בשלב זה נראה אם התצורה נתקעת בדיסק או ברשת, — והפרמטרים מתוקנים עד למצב הסופי.
- בדיקת שלמות. מצליבים את מצב השורש עם מקור ציבורי, מבצעים בקשות בדיקה לבלוקים היסטוריים, משווים תגובות במספר גבהים. בודקים גם את ההתנהגות בהפעלה מחדש: הצומת צריך לעלות בלי סינכרון חוזר.
- ניטור ומסירה. מחברים איסוף מדדים והתראות על פער ושגיאות RPC, מגבילים גישה למתודות כבדות. מוסרים הרשאות, תקנון עדכון הלקוח והוראות שחזור מצילום מצב.
תצורות, תרשיםים ותקנוני תמיכה
צומת ארכיון לא צריך להישאר "קופסה שחורה" שמשרתת רק את מי שהרכיב אותה. אנחנו מוסרים ללקוח ערכת חפצים שלפיה אפשר להעלות את הצומת מאפס, לבדוק את נכונות הסינכרון ולמסור לתמיכה של צוות אחר — בלי שחזורים מהזיכרון.
- קובצי תצורה — פרמטרים של הלקוח (Erigon, Reth): מצב אחסון המצב, מגבלות מטמון וחיבורים, עומק הארכיון. כל ערך מתועד בהערות, כדי שאפשר יהיה לבצע תיקון בלעדינו.
- תרשים התשתית — מפת שירותים, מאגרים ואזורי רשת, נקודות כשל ותלויות ביניהן, חלוקת תפקידים בין הצמתים.
- מדיניות גישה — מי ובאיזה מפתח פונה ל-JSON-RPC, מה פתוח החוצה, כיצד מפתחות מונפקים ומבוטלים, היכן מתועדות הבקשות.
- תקנון תחזוקה — תדירות עדכוני הלקוח, בדיקת שלמות המסד, סדר סינכרון מחדש במקרה של אי-התאמת מצב, חלונות עבודה.
- ניטור והתראות — מדדי פער מהרשת, עומק הארכיון ומקום פנוי, ספים שמעליהם מוקפץ תורן.
- הוראות לפעולות טיפוסיות — נטילת צילום מצב של האחסון, מעבר לצומת גיבוי, נסיגה לגרסת לקוח קודמת.
- תיעוד הצומת — יומן שינויים, אחראים, היסטוריית אירועים והחלטות שהתקבלו.
הערכה נשארת אצל הלקוח ומתעדכנת יחד עם התשתית: שינוי תצורה, הוספת צומת או החלפת מדיניות גישה משתקפים בתיעוד באותו יום. בהמשך אפשר לפתח את התחום בכוחות עצמכם או למסור לקבלן אחר — סף הכניסה יהיה נמוך.
הגירת ארכיון בלי עצירת השירות: מה השתנה
הצומת הפעיל החזיק רק מצבים עדכניים: חיתוך ההיסטוריה היה מופעל, ולכן בקשות עמוקות מהבלוקים האחרונים עברו למקורות חיצוניים או נפלו בפסק זמן. אנליטיקה על חוזים ישנים והצלבת פעולות חיכו לתגובה שניות, ובשיאים הצומת הפסיק להספיק לזרם. חלק מהבדיקות פשוט לא הורצו — בדיווחים נותרו חוסרים.
את הגירת צומת הבלוקצ'יין בנינו בלי חלון השבתה. פרסנו Erigon במצב ארכיוני על שרת נפרד: הוא הדביק את הרשת ואסף צילומי מצבים, בעוד הצומת הפעיל המשיך לשרת תעבורה. את המעבר ביצענו במאזן עומסים — תחילה העברנו את קריאת ההיסטוריה, ואחר כך את שאר הבקשות.
מדדים לפני ואחרי
| מדד | לפני ההגירה | אחרי |
|---|---|---|
| זמינות בזמן העבודות | השהיה להפעלה מחדש של הצומת | בלי הפסקה |
| עומק ההיסטוריה הזמינה | הבלוקים האחרונים | מהבלוק הראשון של הרשת |
| זמן תגובה לבקשה היסטורית | שניות, חלק מהבקשות בפסק זמן | שברירי שנייה |
| חזרה לצומת הקודם | אינו זמין | מיידית, הצומת נשאר מחומם |
את הזמינות בזמן העבודות שמרנו: הפסקה בשירות — אפס, והנסיגה לצומת הקודם נותרה אפשרית עד סוף המעבר. זמן התגובה לבקשה היסטורית הצטמצם לשברירי שנייה, עומק ההיסטוריה גדל מהבלוקים האחרונים לכל השרשרת. מקורות חיצוניים כבר אינם משתתפים בתגובות — הארכיון נענה מצומת משלו.
מה לעשות אם הסינכרון כבר נמשך שבועות?
שבועות של סינכרון הם כמעט תמיד לא "אינטרנט איטי", אלא צוואר בקבוק מוגדר. את התהליך יש לחלק לשלבים: הדבקת בלוקים, שחזור מצב, בניית אינדקסים, בדיקת שלמות. אפשר להיתקע בכל אחד מהם, וכל אחד מטופל בדרכו.
לרוב נתקעים בדיסק. צומת ארכיון של Ethereum כותב בו-זמנית מצב טרי וקורא פרוסות היסטוריות, ולכן העומס על אמצעי האחסון גדל יחד עם גובה השרשרת. אם שחזור המצב נמשך יממות בזמן רשת שקטה, אין טעם להחליף ערוץ — בודקים את פרופיל הקלט-פלט.
האצה נותנת הסרת התחרות על משאבים, ולא דגל נפרד: יותר מטמון למצב, יותר תהליכונים לשחזור, ובזמן ההדבקה — ויתור על אינדקסים מיותרים ופניות חיצוניות לצומת. Erigon ו-Reth מתנהגים אחרת, ולכן הפרמטרים נבחרים לפי המימוש הנבחר, ולא מועתקים מתצורה של אחר.
שווה להרכיב מחדש את הארכיון כשהמצב פגום, האינדקסים אינם מתיישבים או שיש פער של תקופות — אז מהר יותר להעלות מצב מצילום של מקור מהימן ולהדביק את השארית דרך הרשת.
החלפת מצב האחסון מוצדקת כשההיסטוריה העמוקה נדרשת לבדיקות חד-פעמיות, ולא לאפליקציה: צומת מחותך פלוס אינדקסר נפרד סוגרים את אותה משימה בנפח קטן יותר ועולים הרבה יותר מהר אחרי תקלה.
אנחנו מתחילים באבחון: מסירים מדדים לפי שלבים, מוצאים את צוואר הבקבוק ורק אחר כך מציעים הרכבה מחדש או החלפת מצב. כך ימי ההשבתה לא הולכים לניסיונות סינכרון חוזרים.
ספקות טכניים: אחסון, עמידות בכשלים, גישה
צומת ארכיון מחזיק מצב בכל הגבהים, ולכן הדיסק גדל יחד עם השרשרת ומקדים צומת צופה רגיל פי כמה. לקוחות כמו Erigon ו-Reth נבדלים במודל האחסון: מסד אחד גדול יותר, אך זול יותר בפעולות דיסק, והשני קומפקטי יותר. את המרווח מחשבים מקצב מילוי הבלוקים הנוכחי, ולא לפי מספרים ממוצעים מהתיעוד.
כמה מקום יתפוס הארכיון ומתי להרחיב את הדיסק?
הנפח תלוי בקצב גדילת המצב ובאינדקסים המופעלים — לכל סט בקשות מחיר משלו. נתונים ולוגים מפרידים לכרכים שונים, כך שהרחבה לא תדרוש הרכבה מחדש של המסד.
מה קורה לצומת בעת תקלה?
מחזיקים שני מופעים: אחד מסתנכרן, השני משרת בקשות. בדיקת חיות מסירה תהליך שקרס מהאיזון תוך שניות, והמופע המפגר אינו מספק תגובות עד שידביק את הגובה.
כיצד להגביל גישה לצומת?
ממשק הבקשות מאזין רק לרשת פרטית, החוצה מוציא שער עם הגבלת סט מתודות והגבלת קצב. קריאות דיבוג וניהול סגורות, הצומת אינו נכלל בהחלפת עסקאות פומבית.
כיצד בנוי הגיבוי?
אסור להעתיק את ספריית המסד על צומת פעיל — יתקבל צילום לא עקבי. צילום כרך עם תיעוד לוג נותן אי-התאמה של דקות; כמה צילומים אחרונים מונחים על כרך נפרד, ואת הנסיגה בודקים מראש על צומת בדיקה.
נדון במשימה: הערכה, תוכנית וסדר עבודות
הערכה לצומת ארכיון אינה מחושבת "בעין": ארכיון מלא מהג'נסיס לעומת צומת עם חלון היסטוריה מוגבל — אלו דרישות שונות לדיסקים, לזמן הסינכרון הראשוני ולתרשים הגיבוי. כדי לחזור עם תוכנית, ולא עם טווח מנוחש, אנחנו צריכים נתוני קלט לגבי העומס והתשתית.
- פרופיל עומס: אילו מתודות RPC נקראות, כמה לקוחות מקבילים, נדרשת היסטוריה מהג'נסיס או שמספיק חלון של הבלוקים האחרונים.
- היכן פורסים: שרתים משלכם, ענן או היברידי, נפח האחסון הזמין וסוג הדיסקים, רוחב הפס של הרשת.
- לקוח ומצב סינכרון: Erigon או Reth לפי הפרופיל שלכם, התחלה מצילום מצב או מהג'נסיס, חלון אי-הזמינות המותר.
- הרשאות והיקף: מפתחות, רשת פרטית, צומת נפרד לתעבורת RPC, הגבלות לפי כתובות.
- מפרט טכני: הרכב העבודות וקריטריוני קבלה — פער מראש השרשרת, זמן תגובה לבקשה, התנהגות בכשל דיסק.
- תוכנית הטמעה: פריסה, חזרה על רשת בדיקה, חלון המעבר, תרחיש נסיגה בדוק.
- תמיכת הצומת: ניטור עם התראות, עדכון לקוח בלי השבתה, צילומי מצב עם בדיקת שחזוריות, תורנות אירועים.
תארו את המשימה ואת התרשים הנוכחי — נחזור עם הערכה לפי שלבים, תוכנית הטמעה ואפשרות תמיכה לאחר ההפעלה.