https://virgool.io/feed/@saeednick1397 fa 2026-06-17 10:17:47 https://files.virgool.io/upload/users/3033897/avatar/avatar.png?height=120&width=120 https://virgool.io/@saeednick1397 https://virgool.io/@saeednick1397/%D9%BE%D8%B4%D8%AA%DB%8C%D8%A8%D8%A7%D9%86-%DA%AF%DB%8C%D8%B1%DB%8C-%D8%A8%D8%AE%D8%B4-%DB%B3-pgdump-yyytzvro1bnl با ترکیب دستور pg_dump به همراه دستورات فشرده سازی می توان حجم فایل های بکاپ را کاش داد که این موضوع برای بانک های حجیم بسیار مهم است. دستور زیر فایلی برای ذخیره سازی بکاپ مشخص نشده اما بکاپ به ستور gzip منتقل شده و سپس در فایل db1.gz ذخیره می شودpg_dump -U postgres db1 | gzip > db1.gzحالا با دستور زیر بکاپ گرفته شده بر روی دیتابی بازگردانی می شودgunzip -c db1.gz | psql db2اگر از نوع custom یا plain یا tar استفاده کنیم و حجم بانک بالا باشد حجم فایل بکاپ نیز زیاد می شود و متعاقب آن حجم انتقال و جابه جایی فایل حجیم سخت است برای رفع این مشکل می توان pg_dump را با دستور split ترکیب کرد تا فایل های بکاپ با فایل های کوچکتر تقسیم شوند pg_dump db1| split -b 2G - db1حالا فایل ها را به سرور دیگر منتقل کرده و با دستور cat آن را تبدیل به یک فایل db1.dump کرده و یا با دستور دوم آن را در یک بانک جدید به نام db2 بازگردانی یا restore هم می کنیمcat db1* > db1.dumpcat db1* | psql db2با دستور زیر علاوه بر اینکه بکاپ ها را به تکه های کوچک تبدیل کرده آن ها را فشرده هم می کنیم pg_dump db1 | gzip -9 | split -b 2G - db1حالا با دستور زیر آن را restore کرده cat db1* | gunzip | psql db2 سعید نیب سعید نیب Mon, 03 Mar 2025 08:49:38 +0330 https://virgool.io/@saeednick1397/%D9%BE%D8%B4%D8%AA%DB%8C%D8%A8%D8%A7%D9%86-%DA%AF%DB%8C%D8%B1%DB%8C-%D8%A8%D8%AE%D8%B4-%DB%B2-pgdump-odcyogzokfkr سوییچ tکوچک یا table بکاپ گیری تنها از یک جدولمیتوان در اسم جداول از کاراکترهای خاص مثل ستاره برای بکاپ گیری از چندین جدول استفاده کرد مثل person* که از تمام جداولی که با person شروع می شود بکاپ گرفته می شود.با سوییچ -T یا exclude--tableمشخص می کنیم که از چه جداولی بکاپ گرفته نشود مثل جداول logpg_dump -t person* db1 > db.sqlسوییچ nکوچک مشخص می کند از چه schema بکاپ گرفته شود و سوییچ N بزرگ مشخص می کند از چه schema بکاپ گرفته نشود.دستور زیر از تمام schema هایی که با est شروع و با gsm پایان و با west شروع و با gsm ختم شود بکاپ میگیرد به جز schemaهایی که کلمه test دارند.pg_dump -n 'east*gsm' -n 'west*gsm' -N '*test*' db1 > db.sqlسوییچ دستور زیر با دستور بالا فرقی ندارد فقط به جای اینکه دو schema را به صورت جدا معرفی کند یکجا معرفی کرده استpg_dump -n '(east|west)*gsm' -N '*test*' db1> db.sqlنکته ای که وجود دارد چون postgres یک دیتابیس case in setive است و به کلمات بزرگ و کوچک حساس است اگر بخواهیم در اسامی جداول یا بانک ها یا هر اسمی که حرف بزرگ دارد استفاده کنیم باید از علامت "\ استفاده کنیم مثل بکاپ گیری زیر چون اسم جدولی که قرار است بکاپ گرفته شود دارای حروف بزرگ است(MixedCaseName) از علامت "\ استفاده شده pg_dump -t "\"MixedCaseName\"" db1> mytab.sqlاگر فیلترهایی که می خواهیم روی بکاپ بگزاریم زیاد است می توان آن ها را در یک فایل نوشته و با سوییچ filter آن را فراخوانی کرد مثلا از جدول mytable و تمامی جداولی که با table شروع می شوند به غیر از جدول table2 و log و schema test بکاپ گرفته شود. فایلی به نام filte1.txt ایجاد می کنیم که محتویاتش به صورت زیر باشدinclude table mytableinclude table table *exclude table table2exclude table logexclude schema testحالا با دستور زیر بکاپ می گیریم pg_dump --filter=filter.txt db1> db.sql سوییچ zبزرگ یا compress باعث فشرده سازی بکاپ می شودکه از 0 یعنی بدون فشرده سازی شروع و تا 9 یعنی حداکثر فشرده سازی ادامه داردpg_dump -t person* db1 --compress=9 -f db.sqlسوییچ a یا data-only فقط از داده ها بکاپ می گیرد و از ساختار نمی گیرد و بلعکس آن سوییچ s یا schema-only فقط از ساختار بکاپ می گیرد و از داده نمی گیرد.سوییچ cکوچک یا clean باعث می شود ابتدا فایل بکاپ دستور drop database نیز افزاوده شود تا هنگام restore بانک قبلی را حذف کند و سوییچ Cبزرگ یا create باعث می شود ابتدای فایل بکاپ دستور create database افزوده شود تا هنگام بازگردانی بانک ابتدا ساخته شود و سپس بازگردانی داده ها و جداول و دیگر آبجکتها انجام شود.معمولا سوییچ clear و create یکدیگر انجام می شود. سعید نیب سعید نیب Mon, 03 Mar 2025 08:33:05 +0330 https://virgool.io/@saeednick1397/%D9%86%D8%AD%D9%88%D9%87-%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-%D8%AF%D9%87%DB%8C-postgres-%D9%88-%D8%A8%D9%87%D8%A8%D9%88%D8%AF-%D8%A2%D9%86-%D8%A8%D8%A7-pgbouncer-x80tdsn9oykp نحوه سرویس دهی postgres از نظر کارکرد به صورت client/server است.کلاینت همان ابزاری است مثل navicat / pgadmin / psql / java که درخواستی را جهت دریافت یا تغیرر به سمت اطلاعات به سمت postgres می فرستد. server نیز همان موتور پایگاه داده است که وظیفه مدیریت اطلاعات و جواب دادن به درخواست های کلاینت ها را دارد(request).هرگاه درخواستی از یک کلاینت به سمت سرور می آید در سرور یک process(شامل منابعی مثل ram / cpu / .... می باشد)به request اختصاص داده می شود یعنی اگر یک کلاینت ۷ تا درخواست بفرستد باید ۷ تا process در سرور برای آن ایجاد شود این مفهوم client/server است .یک از مشکلات روش client/server همانطور که در بالا گفته شد ایجاد یک process در ازای هر درخواست است که این موضوع باعث مصرف بیش از حد منابع و در اصطلاح در سرور ایجاد سربار یا overhead می کند. با افزایش تعداد کاربران باید منابع نیز به اندازی کاربران افزایش یابد؛ برای رفع این مشکل نیاز به یک ابزار میانی جهت مدیریت requestها است.مهمتری ابزاری که می توان در این زمینه نام برد PGBouncer است.نحوه عملکرد pgbouncer به این شکل است که به جاس ارسال مستقیم به سرور ابتدا request به pgbouncer ارسال می شود بعد درخواست ها با توجه به حجم هر صف در صف های جداگانه ای قرار می گیرند که در اصطلاح به آن ها pool می گویند بعد poolها درخواست ها را یکی یکی به سمت سرور ارسال می کنند. در عکس بالا ۳ کلاینت وجود دارد که هر کدام ۳ درخواست به سمت pgbouncer ارسال می کنند در pgbouncer درخواست ها در pool قرار می گیرند که در اینجا ما ۲ عدد pool داریم و در آخر به سمت سرور ارسال می شود.با این روش به جای اینکه ۹ process در سرور ایجاد شود ۲ process در سرور ایجاد می شود و منابع کمتری تخصیص می یابد. سعید نیب سعید نیب Mon, 24 Feb 2025 17:03:30 +0330