From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 17 Mar 2004 17:56:10 +0200 (EET) From: iceb@svitonline.com X-X-Sender: yuk@iceb.home.int To: "iceb@svitonline.com" Subject: =?koi8-u?B?UmVbNF06IFtDb21tXSDyxdDMycvBw8nRIMLB2tkgxMHOztnIIFBvc3RncmVT?= =?koi8-u?B?UUwgzsEgxNfVyCDLz83Q2MDUxdLP1w==?= In-Reply-To: <498820887.20040317093344@scs-900.ru> Message-ID: References: <20040316083026.664428b5.vahov@dgap.mipt.ru> <1436859241.20040316120431@scs-900.ru> <1045856497.20040316133525@scs-900.ru> <498820887.20040317093344@scs-900.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=koi8-u Content-Transfer-Encoding: 8BIT X-BeenThere: community@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: community@altlinux.ru List-Id: Mailing list for ALT Linux users List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 16:10:07 -0000 Archived-At: List-Archive: List-Post: В Срд, 17 Мар 2004, Evgeny Yugov написал(а): EY> isc> Вовсе нет. Если есть возможность из этого лога получить EY> текущее EY> isc> состояние базы - то почему бы его не rsync'нуть ? EY> А чем вариант rsync в таком случае отличается от pg_dumpall? EY> Все равно старт/стопать базу прийдется... А что, лог транзакций в постгресе формируется только по команде, не в риалтайме ? И для его получения надо базу стопорить ? Так это не лог тогда называется. Ну тогда rsync напускать на всю базу. Не бог весть что, но хоть что-то... EY> EY> EY>> isc> PS. И эти люди что-то говорят о преимуществах EY> перед EY> EY>> MySQL ... EY> EY>> А что мускул умеет реплицировать? EY> isc> Да уж несколько лет как. Я лично его тремя способами EY> бэкаплю: EY> isc> 1) репликация - риалтаймовый бэкап EY> Хм интересно... поподробнее можно? Да в документации все описано, причем на русском языке. В двух словах: при запуске резервного сервера он получает от основного все SQL-запросы на запись, полученные основным сервером с момента последнего их соединения, каковые резервный и отрабатывает на своей копии базы. Если оба сервера включены и соединены друг с другом - то запросы на запись, получаемые основным, на обоих серверах отрабатываются практически одновременно. EY> EY> isc> 2) rsync на дамп и журналы - периодический, раз в час EY> обычно EY> isc> 3) некое подобие (2) на виндовую машину - если EY> поблизости нет EY> isc> линуксовой EY> EY> ps Было бы здорово если бы Вы накидали схемку с коментариями EY> и EY> описанием, многие сказали бы спасибо... :o) Что касается репликации - все (почти) RTFM Справочное руководство по MySQL версии 4.0.11-gamma где-то на http://www.mysql.com. Второй способ - классический, использовался практически на всех приличных СУБД еще лет 20 назад если не больше. Суть заключается в следующем: 1) относительно редко выполняется полный дамп базы данных, на всякий случай с остановом и чеканьем. Получаем большой файл, который ложим на ленту/съемный диск/другую машину по вкусу. 2) после запуска СУБД ведет т.н. инкрементные журналы, в которых в реальном времени записываются все изменения, произошедшие со времени последнего дампа (для первого журнала) или со времени закрытия предыдущего журнала (для всех последующих). Получаем много мелких файлов, причем в ходе работы изменяется только последний. Никакие рестарты при этом не нужны. Полученные файлы тоже сохраняются по мере создания, но времени и ресурсов на это требуется очень немного. 3) goto 1 Понятно, что для сохранения дампа и журналов в сегодняшних условиях удобно использовать rsync (хотя это не единственно возможный механизм). Для восстановления в случае гибели базы она поднимается сначала из полного дампа, а затем по очереди накладываются все инкременты. Более подробно расписывать - времени нет, сорри. Но думаю идея понятна, а подробности - для этого дока есть. -- Yura Kalinichenko