Merge pull request #42 from olshevskiy87/t9

fix backup and clustering punctuation an typos

Author: le0pard

postgresql_backup.tex

@@ -134,7 +134,7 @@ \section{Бэкап уровня файловой системы}
 
 \begin{itemize}
   \item PostgreSQL база данных должна быть остановлена, для того, чтобы получить актуальный бэкап (PostgreSQL держит множество объектов в памяти, буферизация файловой системы). Излишне говорить, что во время восстановления такого бэкапа потребуется также остановить PostgreSQL;
-  \item Не получится востановить только определенные данные с такого бэкапа;
+  \item Не получится восстановить только определенные данные с такого бэкапа;
 \end{itemize}
 
 Как альтернатива, можно делать снимки (snapshot) файлов системы (папки с файлами PostgreSQL). В таком случае останавливать PostgreSQL не требуется. Однако, резервная копия, созданная таким образом, сохраняет файлы базы данных в состоянии, как если бы сервер базы данных был неправильно остановлен. Поэтому при запуске PostgreSQL из резервной копии, он будет думать, что предыдущий экземпляр сервера вышел из строя и восстановит данные в соотвествии с данными журнала WAL. Это не проблема, просто надо знать про это (и не забыть включить WAL файлы в резервную копию). Также, если файловая система PostgreSQL распределена по разным файловым системам, то такой метод бэкапа будет очень ненадежным~--- снимки файлов системы должны быть сделаны одновременно. Почитайте документацию файловой системы очень внимательно, прежде чем доверять снимкам файлов системы в таких ситуациях.
@@ -144,7 +144,7 @@ \section{Бэкап уровня файловой системы}
 
 \section{Непрерывное резервное копирование}
 
-PostgreSQL поддерживает упреждающую запись логов (Write Ahead Log, WAL) в \lstinline!pg_xlog! директорию, которая находится в директории данных СУБД. В логи пишутся все изменения сделанные с данными в СУБД. Этот журнал существует прежде всего для безопасности во время краха PostgreSQL: если происходят сбои в системе, базы данных могут быть восстановлены с помощью <<перезапуска>> этого журнала. Тем не менее, существование журнала делает возможным использование третьей стратегии для резервного копирования баз данных: мы можем объединить бэкап уровня файловой системы с резервной копией WAL файлов. Если требуется восстановить такой бэкап, то мы восстанавливаем файлы резервной копии файловой системы, а затем <<перезапускаем>> с резервной копии файлов WAL для приведения системы к актуальному состоянию. Этот подход является более сложным для администрирования, чем любой из предыдущих подходов, но он имеет некоторые преимущества:
+PostgreSQL поддерживает упреждающую запись логов (Write Ahead Log, WAL) в \lstinline!pg_xlog! директорию, которая находится в директории данных СУБД. В логи пишутся все изменения, сделанные с данными в СУБД. Этот журнал существует прежде всего для безопасности во время краха PostgreSQL: если происходят сбои в системе, базы данных могут быть восстановлены с помощью <<перезапуска>> этого журнала. Тем не менее, существование журнала делает возможным использование третьей стратегии для резервного копирования баз данных: мы можем объединить бэкап уровня файловой системы с резервной копией WAL файлов. Если требуется восстановить такой бэкап, то мы восстанавливаем файлы резервной копии файловой системы, а затем <<перезапускаем>> с резервной копии файлов WAL для приведения системы к актуальному состоянию. Этот подход является более сложным для администрирования, чем любой из предыдущих подходов, но он имеет некоторые преимущества:
 
 \begin{itemize}
   \item Не нужно согласовывать файлы резервной копии системы. Любая внутренняя противоречивость в резервной копии будет исправлена путем преобразования журнала (не отличается от того, что происходит во время восстановления после сбоя);
@@ -171,7 +171,7 @@ \subsection{Настройка}
 /data/pgsql/archives/ > /dev/null
 \end{lstlisting}
 
-В конце, необходимо скопировать файлы в каталог \lstinline!pg_xlog! на сервере PostgreSQL (он должен быть в режиме восстановления). Для этого необходимо в каталоге данных PostgreSQL создать файл \lstinline!recovery.conf! с заданной командой копирования файлов из архива в нужную директорию:
+В конце необходимо скопировать файлы в каталог \lstinline!pg_xlog! на сервере PostgreSQL (он должен быть в режиме восстановления). Для этого необходимо в каталоге данных PostgreSQL создать файл \lstinline!recovery.conf! с заданной командой копирования файлов из архива в нужную директорию:
 
 \begin{lstlisting}[label=lst:backups17,caption=recovery.conf]
 restore_command = 'cp /data/pgsql/archives/%f "%p"'
@@ -182,7 +182,7 @@ \subsection{Настройка}
 
 \section{Утилиты для непрерывного резервного копирования}
 
-Непрерывное резервное копирования один из лучших спрособ для создания бэкапов и восстановления их. Нередко бэкапы сохраняются на той же файловой системе, на которой расположена база данных. Это не очень безопасно, т.к. при выходе дисковой системы сервера из строя вы можете потерять все данные (и базу, и бэкапы), или попросту столкнуться с тем, что на жестком диске закончится свободное место. Поэтому лучше, когда бэкапы складываются на отдельный сервер или в <<облачное хранилище>> (например \href{http://aws.amazon.com/s3/}{AWS S3}). Чтобы не писать свой <<велосипед>> для автоматизации этого процесса на сегодняшний день существует набор программ, которые облегчает процесс настройки и поддержки процесса создания бэкапов на основе непрерывного резервного копирования.
+Непрерывное резервное копирования - один из лучших способов для создания бэкапов и их восстановления. Нередко бэкапы сохраняются на той же файловой системе, на которой расположена база данных. Это не очень безопасно, т.к. при выходе дисковой системы сервера из строя вы можете потерять все данные (и базу, и бэкапы), или попросту столкнуться с тем, что на жестком диске закончится свободное место. Поэтому лучше, когда бэкапы складываются на отдельный сервер или в <<облачное хранилище>> (например \href{http://aws.amazon.com/s3/}{AWS S3}). Чтобы не писать свой <<велосипед>> для автоматизации этого процесса на сегодняшний день существует набор программ, которые облегчают процесс настройки и поддержки процесса создания бэкапов на основе непрерывного резервного копирования.
 
 \input{backups/wal_e}
 \input{backups/barman}

postgresql_clustering.tex

@@ -6,16 +6,16 @@ \chapter{Шардинг}
 
 \section{Введение}
 
-Шардинг~--- разделение данных на уровне ресурсов. Концепция шардинга заключается в логическом разделении данных по различным ресурсам исходя из требований к нагрузке.
+Шардинг~--- разделение данных на уровне ресурсов. Концепция шардинга заключается в логическом разделении данных по различным ресурсам, исходя из требований к нагрузке.
 
-Рассмотрим пример. Пусть у нас есть приложение с регистрацией пользователей, которое позволяет писать друг другу личные сообщения. Допустим оно очень популярно и много людей им пользуются ежедневно. Естественно, что таблица с личными сообщениями будет намного больше всех остальных таблиц в базе (скажем, будет занимать 90\% всех ресурсов). Зная это, мы можем подготовить для этой (только одной!) таблицы выделенный сервер помощнее, а остальные оставить на другом (послабее). Теперь мы можем идеально подстроить сервер для работы с одной специфической таблицей, постараться уместить ее в память, возможно, дополнительно партиционировать ее и т.д. Такое распределение называется вертикальным шардингом.
+Рассмотрим пример. Пусть у нас есть приложение с регистрацией пользователей, которое позволяет писать друг другу личные сообщения. Допустим оно очень популярно, и много людей им пользуются ежедневно. Естественно, что таблица с личными сообщениями будет намного больше всех остальных таблиц в базе (скажем, будет занимать 90\% всех ресурсов). Зная это, мы можем подготовить для этой (только одной!) таблицы выделенный сервер помощнее, а остальные оставить на другом (послабее). Теперь мы можем идеально подстроить сервер для работы с одной специфической таблицей, постараться уместить ее в память, возможно, дополнительно партиционировать ее и т.д. Такое распределение называется вертикальным шардингом.
 
 Что делать, если наша таблица с сообщениями стала настолько большой, что даже выделенный сервер под нее одну уже не спасает? Необходимо делать горизонтальный шардинг~--- т.е. разделение одной таблицы по разным ресурсам. Как это выглядит на практике? На разных серверах у нас будет таблица с одинаковой структурой, но разными данными. Для нашего случая с сообщениями, мы можем хранить первые 10 миллионов сообщений на одном сервере, вторые 10 - на втором и т.д. Т.е. необходимо иметь критерий шардинга~--- какой-то параметр, который позволит определять, на каком именно сервере лежат те или иные данные.
 
 Обычно, в качестве параметра шардинга выбирают ID пользователя (\lstinline!user_id!)~--- это позволяет делить данные по серверам равномерно и просто. Т.о. при получении личных сообщений пользователей алгоритм работы будет такой:
 
 \begin{itemize}
-  \item Определить, на каком сервере БД лежат сообщения пользователя исходя из \lstinline!user_id!;
+  \item Определить, на каком сервере БД лежат сообщения пользователя, исходя из \lstinline!user_id!;
   \item Инициализировать соединение с этим сервером;
   \item Выбрать сообщения;
 \end{itemize}